Devs can now use Google’s Flutter to build apps on Linux

Developers might soon be able to code once, and deploy just-about-everywhere, with Flutter.
24 July 2020

Flutter now available in the Snap Store. Source: Shutterstock

A common developer’s dream is of a single programming framework and language that can be used to publish production-ready applications on just about every platform under the sun. Ideally, developers should be able to write one set of code, and then deploy it — with as few tweaks as possible — onto mobile (iOS and Android), the desktop (Windows 10, Mac, Linux) and the web.

The magic word here is, of course, convergence, which several companies and organizations have tried (remember Windows Mobile?), and many still continue to strive for. The most recent example of work-in-progress is Apple’s decision to roll out “Apple silicon” (aka ARM processors) in its desktop and laptop Macs over the next few years.

Like Apple, Google has a few well-funded and popular tricks up its sleeve in pursuit of the magic “C” word, and the dream has taken a step closer, with Canonical’s creation of a dedicated team to work with Google in supporting the Flutter UI toolkit on Linux.

For those not in the, often opaque, world of development, the Flutter framework is a set of programmer’s tools that helps with the construction of code (written in the Dart language). Already there are around half a million developers using Flutter, according to Google, and 80 thousand apps currently on the Google Play Store built using it. The Flutter framework is available as an open-source entity with a BSD license attached, which gives developers the surety that there’s no hidden malicious or proprietary code being inserted into their creations. In that alone, its potential uptake in the Linux community is given a boost.

Flutter’s spread over the desktop world is a stepwise process, with Mac and Linux desktops supported at “alpha” stage, while Windows 10 support is still somewhat behind the curve, pegged by Google at “early alpha”. Only apps for iOS and Android deployment are currently considered at “production” standards.

Some readers may recall the Flash programming environment and its promise, too, of attractive yet portable applications that would run anywhere that could render a web page. Flutter is seen as being a natural successor to Flash, capable of producing user-oriented applications quickly that conform to visual and GUI standards (Google’s Material Design guidelines), with the latter ensuring high uptake and acceptance levels among end-users.

Since Flash apps died, thanks in no small part to Apple’s rejection of the platform (because they didn’t own it), the convergence torch has been carried and moved on by code bases like Java and Electron, both of which have critics keen to point out their faults. Java is often associated (perhaps inaccurately) as being a source of security concerns, and seen as the purveyor of unwanted commercially-oriented “extras” (completely justifiably), such as the “” toolbar that appeared on bewildered users’ web browsers after Java Runtime Engine upgrades or installs.

Electron, for its part, is often termed cumbersome, as it’s essentially a wrapper around Google’s Chromium code plus a few extra bits and pieces, making it common for the ensuing run-times’ footprints to comprise hundreds of megabytes.

The hoped-for reality in the medium term is that even small developer outfits will be able to create applications on tight budgets, capable of running on multiple desktops, mobile devices and the web. The code-once, deploy-everywhere workflow should encourage the widest possible user base, among end-users and development teams alike.

However, Google’s historical propensity for killing off projects hangs over all things Flutter, making a wholesale jump to the framework unlikely, as yet. But, the fact that it’s also the chosen toolkit for the Google Fuchsia project (a possible Linux competitor) means that Flutter will probably be around for a good while. “A good while” is a timescale that, in developer years, means a long time yet.