A morning with the Google Flutter team

A few weeks ago I hopped on the train down to chat with Tim Sneath at Google’s Pancras Square offices. Tim has recently joined Google as the Product Manager of Flutter , having previously been at Microsoft.

Flutter is a cross-platform mobile application development framework. After a brief visit to their wonderful restaurant, we got down to business chatting about Flutter.

The business case for cross-platform apps

Pocketworks generally builds native apps, which means we build every app twice.

The good thing about this is that we’re always able to build a quality user experience without limitation; we’re using the latest tools as intended by Apple and Google.

The negative is that we have to do everything twice. UI, network code, data access code, unit tests and manual tests. These are all done twice for any consumer app that needs to reach users on both iOS and Android.

This is why we often take a look at cross-platform frameworks like Flutter, Xamarin, React Native and Cordova. We don’t really want our clients to have to pay almost double to be on two platforms.

The interesting thing about Flutter

What interested me most about Flutter was that it’s not native, it’s not it relying on javascript like react-native, nor does it rely on web rendering like Cordova. So, how does it work ?

Instead, it runs a virtual machine inside a native app. This virtual machine runs the Flutter stack, which has it’s own UI libraries for rendering screens. It has its own inbuilt graphics engine running at 60fps. This is kind of cool, risky and controversial. I was thinking “how can Google sustain this? How can it create an experience that matches native apps as they claim?

Rebuilding the native UI

In order to create a native-like experience, the Flutter team have had to rebuild the native widgets using their own graphics engine. They explained how they would, at times, have film Apple animations and play them back in slow-motion – just so they can get the animations right. Sounds like Google are pretty serious about recreating the experience.

We previewed an app on the store and it certainly looked pretty slick. It felt good.

What’s to like about Flutter?

• If it’s as good as it sounds, it will reduce development costs for an app on 2 platforms
• It’s cross-platform (obvs)
• It’s not using web-views or Javascript
• It has nice VS Code and Android Studio support, including debugger
• It’s backed by Google
• It has its own headless unit test runner
• Dart seems pretty nice as a language
• It has a built-in network library, so shared API code
• You can build native features in the host apps to handle things that Flutter cannot
• Command line tooling
• Rich set of visual components
• It’s well documented, was easy to get up and running
• There are apps published to the stores using it, not as Alpha as they say it is
• It’s open source, you can extend it and mess with it

What’s not to like?

• It’s backed by Google, who are known to kill their own projects
• The “rebuild the native UI” approach will take a lot of effort from Google to sustain long term
• No cross-platform data access libraries built-in
• Developers might not want to abandon their native skill-sets

Interested?

If you’re a business interested in experimenting with this new cross-platform technology, feel free to talk to us about creating something. If your project is reasonably high-profile, you’ll have an opportunity to gain some joint PR with Google.  At this point, we’re very interested in trying the framework. Please get in touch if you’re interested in trying Flutter and potentially reducing the required investment by using this cross-platform technology.