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 simple as the snap method. Essentially you clone the Flutter SDK GitHub repository, and an upgrade would pull the latest changes and then kick off some compilation and other companion tasks based on the refreshed source.

Systemd penetrated almost all the Linux eco-system: on one side rooting from Debian and its biggest derivative Ubuntu (and a whole bunch of Ubuntu derivatives) and on the other side throughout the other largest derivative tree which is based on Fedora / RedHat. The latter distribution family tree is not a surprise because systemd originates from Leonard Poettering, a software engineer at RedHat, 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. A big advantage of snaps is 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 installing it with just a single snap command.

At the same time, Flutter has 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 operate through Flutter CLI 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 in 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 many developers simply install Flutter via brew because they see that it is available there and it’d be a one-command install just like in the case of snap. Brew is very up-to-date and it already offers the 2.8.1 stable 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 you there’s a new version available don’t fall for that and stick with the CLI.

Flutter SDK 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 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 a snap package 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 can not only advise of overriding, but with some distributions snap will upgrade automatically. That can be a problem, so watch out!