Flutter — The sky’s the limit
Some of you probably get the pun already. The Flutter project was initially known as the Sky Engine. If you look closely into the project’s GitHub repo you may find the very first commit by Adam Barth:
commit 00882d626a478a3ce391b736234a768b762c853aAuthor: Adam Barth <abarth@chromium.org>Date: Thu Oct 23 11:15:41 2014 -0700Open the Sky
A humble beginning
Flutter started as an attempt to move forward or more precisely fast-forward the evolution of the web. When I heard about it for the first time in 2014, it was only a very enigmatic prototype of the engine allowing hot reload of the executable on an Android phone. After that, I didn’t hear much about it. The project just vanished from my radar.
In November 2016, Google reached out to TAB to see if there was interest participating in an Early Access Programme for the ‘new cross-platform tool for mobile.’ As mobile specialists, we were thrilled to try it as soon as possible. We knew all too well the pain points of mobile development. In May 2017, just after Flutter Beta was made public, we decided to rewrite our internal Status App in Flutter. It took us just a single day to learn how Flutter works and the basics of Dart.
Quickly, we realised that Flutter is unique. Despite traits derived from its predecessors like view immutability or reactive views, it showed a very distinctive freshness. Fresh tools, a new drawing pipeline, and UI toolkit. A clean slate all the way from the DOM to the rendering layer. This particular approach may have its disadvantages, but it also has massive advantages.
Independence
Eric Siedel said that cutting off the legacy was a principle from the very beginning of the project. The Flutter team achieved absolute freedom in shaping the framework, unconstrained by any form of dependency. If you look closely into the Flutter stack, you may notice that there is very little there, apart from bits that the Flutter team has control over — Dart and Skia.
Because of this decision, Flutter is able to run the UI on mobile devices with a perfect 60 fps, achieving the speed of native UI without actually using it. However, this wasn’t the only good thing that came from independence. The Flutter team was able to achieve unprecedented development speeds, creating new UI paradigm which increased the productivity of the app developers without sacrificing the performance of the final product. Unblocked through most of the time the Flutter team didn’t have to tiptoe around limitations of third parties or compromise on the primary goal. The team was always in full control of the framework. When I look at it now, it reminds me of another technical marvel build in the same way — SpaceX Falcon 9 rocket.
True portability
Independence also brought the hallmark of Flutter — Portability. As the engine renders all by itself, it doesn’t require any extra help from the host system apart from a link to OpenGL, Metal or Vulcan frame. All it needs is a plain canvas on which it paints its beautiful UI. It’s like watching your favourite movie — all you need to enjoy it is a screen.
Initially, Flutter was targeting mobile platforms only — iOS and Android. At some point, we noticed a trace of the Google enigmatic operating system Fuchsia in the GitHub, but we knew that this wouldn’t be it. In summer 2018, we found a flutter-desktop-embedding repository in the Github which allowed users to run executable on Windows, macOS, and Linux. It was only a very early prototype. However, it was good enough to attract the attention of one of our major clients to see what could be achieved with it.
At this point, our perspective on Flutter changed dramatically. It was no longer the question of Flutter vs. ReactNative or Flutter vs. native iOS and Android. Flutter became an alternative to Electron apps crossing iOS, Android and all desktop environments.
Read more here: https://medium.com/flutter-community/flutter-on-desktop-a-real-competitor-to-electron-4f049ea6b061.
We were proud to find that mobile wasn’t the only place for Flutter. Little did we know of what was to come.
Hummingbird
During a FlutterLive event, Tim Sneath announced they were focussing their efforts on the very platform it came from — a web browser. There were many prototypes and there were many options on the table. Please read Yegor Jbanov’s blog post on it.
Flutter is now close to running on all possible channels, making one fast and modern framework run on virtually anything.
Disruption comes
Let’s rewind a bit to March 2018. The App Business has started a Flutter project for their long-standing client dunnhumby. With little knowledge of ‘Good Flutter Practices’, a basic understanding of how we CI and automated testing mixed together with Flutter, we’ve started developing the app. We have found bitrise.io CI among the first who was supporting Flutter iOS and Android builds and had a dedicated plugin for it. Our team was able to establish a very elaborate CI pipeline with multiple environments and workflows spanning from pull request to pushing to App Store and the Play Store. The team has solved many problems including obfuscation of Android code, integrating with third party libraries, navigating to native parts of the app without losing Flutter context, permissions on iOS, creating new plugins for the app (AppsFlyer) and learning more about architecture for Flutter. We have thrown away most of our usual Android and iOS architectural concepts because Flutter code feels more reactive, and less like native mobile code. SOLID — stays.
Integration with the backend was a walk in the park. Most of the communication was facilitated by Firebase plugin which gave us nice reactive API to drive our reactive views. Thanks to Google Cloud Platform, we were able to get Firebase, Storage, Functions, Sign in, Analytics, Vision API and Big Query in one box. To configure that all we had to add just 2 files to the client project.
We were expecting that we will be changing the designs all the way through. At TAB we have this golden rule which is for iOS and Android development — no development before official sign off of designs from the client. Each story, the client approves each screen before its construction begins. This rule, however, has proven to be utterly obsolete in the case of using Flutter.🎉
Hot reload
I can’t stress enough how important this feature is. It is the beating heart of Flutter itself. It’s not about the magical 400ms instead of 7 minutes of an average Android build. It’s about learning it fast, being super productive, training people faster than ever and having pure fun at the same time.
Flutter is so fast in creating and modifying UI, that it doesn’t make sense anymore to separate design and development stages. With Flutter projects the designer should be sitting between developers, interacting with them all the way through, enhancing the design and shortening the takt time. If a client requests any changes to the design, your team can effortlessly implement them just before peer review.
Testing
Initially, we’ve had a bit of trouble starting Flutter Driver automation on iOS simulator, but this was fixed somewhere in April. We have ditched our first test suite created using Appium to develop UI automation using Flutter Driver directly. To keep track of all the changes happening to the UI, we have established automated tools to compare screenshots of every screen in every build. For us, using the Flutter test suite was also a dream come true — one set of tests for all devices and all platforms.
The team has published the first release in July, and since then we have upgraded the app with new features five times.
One observation which was brought to my attention during the project was the growing cross-functionality of the project. Automation testers writing cloud functions, Designers creating pull requests with UI tweaks were commonplace. Our designer Antonio Bertossi articulated this as Team’s Compassion. You need to be compassionate for your teammates to understand better what challenges they are facing and make you more effective in creating the output which is more easily consumed by your peers.
Where do I get Flutter developers from?
It is becoming an old joke now. You already have them. They just don’t know that yet.
Our front-end team was composed of two platform developers — iOS and Android and a group of very junior or even intern level developers, some of them doing their summer internship. Platform leads were providing all the knowledge on how to integrate the app with the underlying host system. They were also maintaining the architecture of the app. Juniors and interns were developing UI stories. Usually, it took about 3 days to onboard an intern with no previous knowledge of Dart or Flutter. Our resourcing team were in disbelief when we asked for more interns.
Let me state this clearly, you still need Android and iOS developers, however, you no longer need an army of them. Their specialist skills are now better used to provide full support for Flutter on their platform. At the same time, you have an easy way to onboard all developers into mobile development, especially web developers to which concepts of Flux and Redux are bread and butter now.
A peaceful Friday
We know very well that releasing on a Friday is not a good idea unless you love to waste your weekend triaging and hot-fixing. However, that Friday was the most peaceful release I’ve ever seen. All boards were green, and regression testing was done without much effort (because you don’t have to test on all versions of iOS and Android). We presented the client with consoles to push the publish button for both platforms. Our confidence in Flutter has built over a couple of months with the culmination of this one Friday. We have proven to ourselves that we can create much more exciting UI and create much more if we work with Flutter. All members of the team are aligned with their experience that this was the fastest moving project they have worked on.
What should you expect from Flutter?
It is highly portable which means it can run on virtually anything which has an OpenGL, Metal or Vulcan rendering capability. Mobile phones are the obvious target but desktops and Raspberry Pi as well.
It has extremely flexible UI allowing the user to create experiences easily which before were usually reserved for the most expensive and time-consuming projects.
It is straightforward to learn. It makes your resourcing problems disappear. Flutter also makes projects run smoothly and leaves enough time to make all these extra steps to polish the app before the release. It also enables cross-functionality.
It is highly performant exceeding our expectations allowing our app reach the fidelity we couldn’t afford earlier.
Thank you for your time and hopefully, we will see each other during FlutterLDN and GDG London meet-ups.
Check out more insights on our main blog: theappbusiness.com/insights
