Installing Flutter SDK via Snap or Brew

Ubuntu is the most popular desktop Linux distribution, especially if we count all of its derivative Linux distributions. The relationship between Ubuntu and Flutter is getting tight: the Ubuntu operating system installer got implemented in Flutter lately. Another new change of the latest Ubuntu version is that the built-in software store is based on SnapCraft and users would pick and install snaps rather than Debian packages via apt.

This use of Snap circles back to Flutter: currently the primary advised installation method of the Flutter SDK on Linux is via snap. Snap has a package dependency on systemd, and since I use systemd-less Debian flavor called Devuan I had to go the secondary way: install Flutter SDK manually. Manual installation is almost as simple as the snap method. Essentially you clone the Flutter SDK GitHub repository, and the flutter upgrade would pull the latest changes and kick off some compilation and companion tasks based on the refreshed source.

Systemd penetrated the whole Linux eco-system: on one side there is Debian and its biggest derivative Ubuntu (and a whole bunch of Ubuntu derivatives) and on the other side the Fedora / RedHat based derivative family tree. The latter distribution tree is not a surprise because systemd originates from Leonard Poettering, who is a software engineer at RedHat and a long time Linux contributor. Even if someone is not using Ubuntu, snap is available as a native package and, with that, we create an extra layer of package distribution eco-system above the operating system’s native package management (the native uses deb packages with apt / dpkg on Debian and rpm packages with yum or dnf). A big advantage of snaps are that you won’t hit any dependency roadblocks because snaps are self-containing. You can also easily switch between various versions of software or SDKs. Although the manual installation of Flutter is easy, nothing can be easier than installation with literally just one click or command.

At the same time, Flutter has a very low friction and awesome CLI. Developers can extremely easily get information on the healthiness of their Flutter installation (flutter doctor), upgrade to the latest version (flutter upgrade), or switch between stable / beta / nightly distribution channels. The question arises: once someone installed Flutter via snap or brew, how should it be kept updated? On one hand, various IDEs (Integrated Developer Environments) like Android Studio or Visual Studio Code will check time-to-time and warn if a newer Flutter version is available. These tools use the Flutter CLI underneath and would promote a flutter upgrade. However, Snap as a package distribution eco-system would also - supposedly - have new versions of the SDK time-to-time and would warn about those through their native warning channels respectively.

The same question would arise on Mac OSX environments too. The official Flutter documentation only outlines the manual installation on OSX however I can guarantee that every developer already has the homebrew alternative package management system on their machine. Therefore several developers simply install Flutter via brew because they see it being available there and it’s a one click install just like in the case of snap. Brew is very up-to-date and it already offers the 2.8.1 stable Flutter version which came out almost two weeks ago. My fellow developer was not able to simply upgrade to that package though, so some force is needed by brew upgrade –greedy. Also, see this or this.

The thumb rule is - and this is why I’m writing this post - that SnapCraft or HomeBrew based installation methods only provide an installation vehicle. Every developer should provision their Flutter SDK via CLI commands (or the IDE - which does the same). When Snap or Brew tells there’s a newer version available don’t fall for that and stick with the CLI.

Flutter SDK’s GitHub repository would always certainly provide the most up-to-date version, while Snap and Brew packages could follow the changes after some lag, or sometimes more significant lag. But that’s fine because the installation step immediately follows up with a flutter doctor right after installation and that should guide the developer towards an immediate update if needed.

Package version of the Snap can lag by design: in an unrelated issue in October I realized that a fellow Linux user-installed Flutter from snap and SnapCraft at that time had a very old package (built in August) offering an even older SDK version (2.2.1 is a version from May). The Linux user thought that after the snap install, he would have the latest version. After raising two issues in the Flutter GitHub repository (see Flutter Snap package is extremely outdated #93495 and Snap builds are not triggered for several months now #93497) it turned out that the CI/CD (Continuous Integration / Continuous Delivery) pipeline had a mechanism to build snap package artifacts but that got mute after some storage bucket changes. That issue got solved and there was a new Snap build on November 15th as a result. I opened a regression ticket as well (Snap package version is lagging behind #95989), and also got directed to the Canonical Snap repository, where I got a clear signal that the CLI is the way to update.

Then I realized that even if the snap packages would be semi up-to-date that could still pose a dual signal, and it would be good to have a clear policy on how someone is supposed to keep the Flutter SDK installation up-to-date. Unfortunately, the package manager can interfere and may advise overriding a fresher local state with an older version? These are not infrastructure issues but rather documentation issues so I opened tickets about the Linux installation (PAGE ISSUE: Linux install #6460) and declaring the policy on upgrade when installing from a side-channel (PAGE ISSUE: Declare clear upgrade policy when installing the SDK via snap on Linux #6499).

Edit (April 26 2022): the extra package manager layer can not only advise of overriding the current (and potentially newer) install, but with some distributions snaps could upgrade automatically. That can be a problem, so watch out!