Flutter, the new cross-platform mobile SDK

There are countless ways of developing cross-platform mobile applications. The most obvious are native applications, based on tools specifically developed for their respective platform (Google’s and Apple’s). However, they force you to re-create a separate yet identical application with different and non-portable code, which makes this an expensive proposition. Then, there are several ways of working from a single codebase, each with its advantages and drawbacks. For example, you can use a C# codebase with Microsoft’s Xamarin, use Web technologies (CSS3, HTML5, JavaScript) with Apache Cordova, or build applications solely based on JavaScript with Facebook’s React Native framework. Or, you can turn to the very limited progressive Web applications supported by Google Chrome. And there are plenty of other options, some more proprietary and efficient than others. You can even mix and match. But for reasons that only Google knows, it has decided to offer yet another option for cross-platform mobile development, separate from its Android tools: Flutter, the open-source SDK.

On February 27, Google released the first beta version of Flutter; on December 4, it organized a special event at London’s Science Museum, dubbed “Flutter Live”, to launch version 1.0 of its SDK in style. It seems that Google has high hopes for its latest debutante.

Flutter is based on the Dart programming language, specifically developed for cross-platform mobile development. Launched by Google in 2011, version 2.0 came out last August. This language, whose usefulness remained to be proven, never made inroads outside the Googleplex and never gave rise to its own community, whose supposed members might have frequented GitHub, Stack Overflow, Freenode, or any other forum. Which isn’t to say that it didn’t win accolades, most notably Codementor’s mention for top language not to learn in 2018, beating out Objective-C, CoffeScript and Erlang. We’re not saying it’s not a good language--just that it hasn’t met its public yet; but Flutter may perhaps, and probably will, bring the two together. Besides, if you already know Java, JS, Kotlin, Swift or C#, this language is easy to learn.

Flutter uses its own rendering engine based on Skia’s 2D graphics library, which was bought out by Google in 2005, subsequently made available under modified BSD licence, and now used by Chrome OS and Google Chrome. And that’s when you start seeing a noticeable difference between this and a purely native application: instead of using system graphics components, Flutter draws everything, including to-the-pixel perfect reproductions of iOS interface elements and Material Design components for Android. This is also a radical departure from a typical React Native or Xamarin application, where the properties of graphical interface objects can be supported in different ways, depending on whether you’re working with iOS or Android.

To give you an idea of the difference between Flutter and other solutions, Tim Sneath, formerly from Microsoft and now Product Manager for Flutter, says: “For us, the closest analogy is not a cross-platform framework, it’s something more like Unity. Unity’s a games engine, you’re writing code that runs super well on both platforms and its engine is optimized for great gains.”

Google’s value proposition rests on three pillars:

Fast development. One of Flutter’s sexy functions is the “stateful hot reload”, which allows you to instantly test the effect of changes to your code without endless compilations – an appreciable time-saver. For development purposes, plug-ins have been developed for Visual Studio Code, Android Studio and IntelliJ environments.

“Native” User Experience. We put the word Native in quotes for two reasons: though you can reproduce a seemingly native user experience, the fact is that it doesn’t use system components, but rather reproductions generated by Flutter’s rendering engine; and also, you are free to do whatever tickles your fancy. Flutter is fully in control of the UI, to-the-pixel, letting you use this power any way you want. For example, you can use the Cupertino library, which mimicks iOS, or create your own UI from scratch (for better or for worse). And if a system component evolved over the course of an update, the version that was compiled with your application is set in stone as long as you don’t release a new version. In other words, in the future, some Flutter applications could reproduce an obsolete user experience.

Native Performance. Probably. Flutter’s greatest attraction is to provide true 32/64 bit compilation for ARM processors. Contrary to other solutions, no code interpreter, usually JavaScript, will slow execution. As for performance, it comes close to a purely native application.

Finally, it’s worth noting that Flutter has set its sights beyond mobile. Tim Sneath writes: “The primary target for Flutter has so far been iOS and Android. Yet our ambitions for Flutter extend beyond mobile to a broader set of platforms. Indeed, from the outset Flutter was architected as a portable UI toolkit that is flexible enough to go wherever pixels are painted.” In the future, Flutter could be used to develop cross-platform desktop applications – Windows, Mac OS and Linux.

In the meantime, Flutter looks to us like a promising solution that sidesteps the usual trade-off: a slow application, a non-native-looking application, or an application for which you have to write two versions. And since Flutter is going to play a leading role in the very mysterious Fuchsia OS, it may be wise to bone up on Dart right away.

Want to dig deeper? May we suggest the following brief introduction to Flutter programming, published by Android Authority. And to dive right in, check out the official documentation.