Flutter — NOT yet another x-platform framework

Flutter — NOT yet another x-platform framework

Having painful experiences with NativeScript and a failed proof-of-concept (PoC) React Native, especially on Android, our development and Executive teams are terrified of any further mention of cross-platform mobile frameworks. However, when approaching Flutter, we believe it is NOT yet another cross-platform mobile development framework. And this is not a pure faith, but based on observation and analysis of (1) its technology, (2) the community adoption, and (3) most importantly, the strategy of Google — its original author and backer.

Flutter Trinity

Warning: This article is a little bit like “Flutter vs XYZ”, and in some way it is, but from a perspective of my own experiences and journeys leading teams and hands-on with those technologies. My intention is not to cause a flamewar. I have no affiliation with Google or its projects either.

0. Miserable with the status quo

During the time I was working at my previous startup in Finland, I had to make many technological decisions, among which was unfortunate, NativeScript (at that time, was with vanilla JS, i.e. without Angular2 framework). Coming to the current company, Inspectorio, it was coincidental that the same decision had been made, with the same consequences. Lack of proper first-class test automation support (any level, such as unit, integration, e2e), lack of first-class productivity tools (debugger, inspector, stack tracing), dependency hell (ironically it was advertised as NativeScript strong point, not to wait for NativeScript version to catch up with new iOS or Android, but in fact every new iOS crashed our app written with NativeScript, while updating framework dependencies took the team of 4 more than a month on average), performance hell, especially on Android, and freaking hard to write anything in ObjC/Swift/Java/Kotlin.

Having that bad experience, we were a little more conservative when considering React Native for our next project. The pros are straight forward, modern declarative/reactive programming pattern, gentle learning curve¹, same tech stack considering our team has been doing React-Apollo-NodeJS. However, as we had been afraid, React Native PoC failed on certain criteria (a) Android performance, especially camera (b) dependency management (to eject or not to eject), and (c) interaction with IoT devices.

Before buckle up on our journey, it was worth noting that in my previous startup, we did evaluate Xamarin and RoboVM as well.

¹ To be exact, the learning curve of any JS-based cross-platform mobile development solution is gentle when making a simple demo app, but steep when working with a testable, extensible, performant app. Programmers always have to refrain themselves from “crossing the bridge”, but on the other hand, any UI or animation can only be done from “the other side”.

1. The Technology

3 points: tools, rendering engine, compilation modes

Tools

Firstly, when I assert Flutter is NOT yet another cross-platform framework, it is because Flutter is NOT a framework, but an SDK. In a nutshell, SDK is bigger than a framework. A decent SDK has all the tooling, such as debugger, inspector, profiling, stack tracing, testing framework. Our teams were amazed by how well the toolings support for Flutter is. Web developers feel familiar with Flutter widget inspection, while the performance overlay is just perfect for optimization maniac. All of this is because Flutter development tools are first-class supported in Android Studio.

Web developers feel familiar with Flutter widget inspection, while the performance overlay is just perfect for optimization maniac.Flutter development tools are first-class supported in Android Studio.

Flutter’s document on testing (on any level, including instrumented UI test) is well written with easy-to-understand examples.

With all of these tools, we are relieved from one of the chronic problems of other cross-platform mobile development solutions.

Rendering engineIllustration reproduced from What’s Revolutionary about Flutter, highlighted by the reproducer.

Unlike any other data-intensive cross-platform mobile development solutions, Flutter ships with its own rendering engine — Skia with the ambition to achieve consistent 120 fps on supported devices (and 60 fps on common devices). Meanwhile, NativeScript, Xamarin, React Native all use `UIView` rendered by platform (e.g. iOS 12, Android 7, etc). In fact, the only other notable mention of cross-platform mobile development solutions is Unity (as Qt already gave up), a game engine. A Google Developer Expert (GDE) has a crazy enough idea to write a Flappy Bird game in Flutter.

Now that Flutter has its own rendering engine, fancy UI and animation no longer requires programmers to “cross the bridge”, which significantly improves the UX/smoothness of any app written in Flutter. Also, because Flutter has full control over the rendering engine, it can easily introduce the declarative programming pattern with Widget and Widget composition, which also boosts the development productivity with extensible and testable code. As crossing the bridge is reduced to the minimum, major OS upgrades is no longer a threat to app crashing, while Flutter SDK version upgrades are no longer associated with dependency hell either.

On the other hand, the only reason to “cross the bridge” now is to get “services” data (including our use case for IoT devices), and even then, it is much easier to do than with other JS-based solutions.

Compilation modes

Arguably, having different compilation modes (thanks to Dart toolchain) is THE killer feature of Flutter, as it brings the best of both worlds, sub-second hot-reload during development, and bare-metal-performance for CPU-bound tasks in production. It is also the reason Flutter goes with Dart but not other languages.

2. The Community

3 points: designers, programmers, contibutors

It is funny how we heard of Flutter, as it was from a designer! As funny as it seems, it highlights one important aspect of Flutter, that it is design-centric, or even design-first. Material design announced that Flutter is their first-class platform. Apparently, mobile development, especially cross-platform mobile development, has a notorious reputation within the designing community, and Flutter knows exactly how to stand out. Flutter achieves this by having the sub-second hot reload as discussed above, together with the technical decision to prefer Composition over Inheritance, allowing programmers to achieve the desired design in record time. Moreover, because it has its own rendering engine, achieve consistent brand-identity design is easier and faster than using OEM widgets.

But of course, the main community of Flutter is the programmers. Thanks to the gentle learning curve of both Dart language and Flutter declarative Widget composition pattern, Flutter is THE Fastest Growing Skill Among Software Engineers according to LinkedIn (as of March 2019).

Talking about open source repository activity, among all the cross-platform mobile development solution, only Flutter and React Native are comparable (the others are so far behind). Looking at all the figures, it is amazing to see how Flutter repo on Github catches up, and in some metrics, surpasses React Native, which is much older.

3. The Strategy

Among all the players, only Google has both the resources and incentives to see Flutter take off.

However, technological superiority or community adoption are not only the reasons that make Flutter standing out from other cross-platform mobile development solution. In fact, the most persuasive reason Flutter is a real deal is the how much resources Google has poured into this technology, and how much is at stake that Google would like to see this technology take off.

Before going any further, it is worth mentioning that NativeScript and React Native are open source, while Xamarin has been open source recently (it was not when we did the evaluation in my previous startup), and so are Android, Kotlin, Flutter, Fuchsia and Dart.

Firstly, NativeScript comes from Telerik, a sizable software company, has been acquired several times on several levels, but in no way comparable to Facebook or Google. They of course have the incentive to see NativeScript take off to sell consulting service, but they just don’t have the resources to make NativeScript a phenomenon.

Telerik has been acquired several times on several levels, and currently is a subsidiary of Progress.

Secondly, Xamarin was originally created by the engineers that created Mono. At that time, their business model is to sell development license per developer (cheapest option was $25 per developer per month if my memory serves). Then in 2016, Microsoft acquired Xamarin Inc. and made the project open source. Their plan was to lure developers to use Xamarin as a cross-platform solution to build mobile apps for Android and iOS, while Xamarin also happens to support Windows Phone. Microsoft has the resources and the incentive to make Xamarin take off to save their deserted Microsoft Store and Windows Phone, but as it turns out, they did not allocate enough resources, while Windows Phone dies out.

Xamarin has also been acquired, and now a subsidiary of Microsoft.

Next is the hot kid, React Native. While Facebook has resources to bring React Native to the next level (similar to what they did with HipHop for PHP), they just don’t have the incentive to do so. Mobile software development is not their core business, at least not that we can see. It seems that React Native only serves as their quick way to do PoC or prototype for some new crazy ideas over a weekend hackathon. Another big contributor of both React and React Native, Airbnb, also sunset React Native.

Facebook has resources to bring React Native to the next level (similar to what they did with HipHop for PHP), they just don’t have the incentive to do so.

Before analyzing Flutter, let’s talk about Android. Android Inc. was acquired by Google in 2005, which turned out to be a smart move considering the first iPhone ever was launched in 2007. If only Google had been complacent or ignorant like Nokia or Microsoft at that time, the mobile market share would have been totally different.

Nokia One billion customers — Can anyone catch the cell phone king? Forbes Magazine 2007

2007 Forbes Magazin cover, © Forbes

However, in 2010, 5 years after Android Inc. acquisition and 2 years after the first commercial Android device launched, Google was dragged into a lawsuit battle with Oracle over the copyrights and patents. Until January 2019, the lawsuit is still ongoing with a petition for writ of certiorari filed with the Supreme Court of the United States. Apparently, for Google, Android is the goose that laid the golden eggs, but it’s too costly and risky to keep it in the long run. Java, the soul of Android SDK, is also in love-hate relationship with programmers all around the world. With the pressure from Swift for iOS introduced in 2014, Google had to announce official support for Kotlin for Android in 2017. It is true that Kotlin language and toolchain themselves are open-source, but the language committee has too much influence from JetBrains (and deservedly so), which again is a risk for Google moving forward.

We almost arrive at Flutter and Dart, but let’s delay one more time to talk about Fuchsia OS, which is rumored to run on many platforms, from embedded systems to smartphones, tablets, and personal computers, and has Zircon kernel instead of Linux one. It is true that Google has many failed projects in the past, but just imagine what is at stake for Google to see Fuchsia OS eventually replace Android OS, wouldn’t all the risks mentioning above be mitigated. Unsurprisingly, Fuchsia’s UI and apps are written with Flutter.

Imagine what is at stake for Google to see Fuchsia OS eventually replace Android OS.

So, Dart, Flutter, Fuchsia, even though they are all open-source, Google has much better control over them compare to Kotlin in terms of technical development, and Android in terms of patents and copyrights. It is a no-brainer to see why this is a high-stakes game for Google to see Flutter take off. Their contingency plan, in case Fuchsia OS ends up like Google+, is still to have Flutter SDK to replace Android SDK and NDK to unify the development experience on Android.

If you ask any Google employees, however, the only answer is that Google is not going to depreciate Android, and that Android itself is open source, the community can take it above and beyond. Of course, as big as Google is, they don’t want to risk having Osborne effect.

Oh, and one more thing, as React surpasses Angular as the most popular Web rendering library/framework, Google is also planning to have Flutter’s sibling, Hummingbird, to resume the race.

React surpasses Angular as the most popular Web rendering library/framework

Conclusion

With its revolutionary technical approach, a strong and dedicated community, and a corporate strategy of its original author and backer, Flutter has all it needs to be the next big thing.

Flutter — NOT yet another x-platform framework was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.