Last Tuesday, Google launched the first stable release of Flutter, its open source, cross-platform UI toolkit and SDK. Here at In The Pocket we watched the livestream of the launch with some beers, pizzas and tons of enthusiasm. Before and after the presentation I (Thomas, a Flutter rookie) had met up with Bram (our Technology Manager) and Yves (our Xamarin Lead and avid Flutter enthousiast).

If I have understood correctly, Flutter will ensure that we no longer have to develop an Android and iOS application separately, but we just have to build one? Or am I too naïve?

That is of course the goal of every cross-platform framework. Both Xamarin and React Native want to achieve the same goal, but important to keep in mind is that none of these frameworks are the silver bullet. You can’t expect to just choose 1 framework and be able to create all possible apps with it. We still look at each app’s requirements individually, and decide which approach (native or one of the cross platform frameworks) is best suited to address its specific requirements. Flutter offers us yet another, and dare we say, very powerful means to create beautiful apps using a single code base.

Why did Google launch this Toolkit? The first thing that comes to my mind is that there were several applications that were first released on iOS and only months later on Android - a scenario Google would prefer to avoid?

That might be one of the reasons indeed, but as we’ve seen in the keynote, Flutter doesn’t limit itself to just Android and iOS in fact. With a bit of work, developers will be able to create desktop applications, as well as web applications with Flutter, and most likely even Fuchsia apps in the future. We think that with Flutter, Google wants to create a universal way to develop apps for all kinds of platforms, with an easy to use, easy to extend toolkit. Of course, Flutter is a Google product, so this is another way to bind developers to the Google ecosystem, and let them use more Google products along the way (which is not necessarily a bad thing).

Does this change anything for us?

We think it probably will. Flutter has been in beta since earlier this year and we’ve been experimenting with it along the way, but there was always some hesitation from other developers because of that ‘beta’ label, which is considered as unfit for production. And as we’ve seen in the past, Google might start on a product, but halt development before an official version is released. Now that this first version is officially out of the box, more people will most likely start experimenting with this.

With the 1.0 release, it is now also “safe” to use Flutter for client applications. While the benefits are clear, it’s still risky to create a long-term product, based on a beta framework. With this stable release, we can build up some more experience with it, and let our clients reap the benefits.

‍Flutter isn’t the first attempt to create something cross-platform as you’ve mentioned, there’s React Native, Xamarin and others, why would Flutter be different?

For this, we need to have a look at the different aspects of each framework. In native Xamarin, which is C#, the focus is on sharing the business logic of the mobile applications. Xamarin Forms adds a layer on top of this, so the UI can be shared as well, but it still renders to native elements. Xamarin is a great way to have cross-platforms apps, where you have the choice of still having a very custom layout by using native Xamarin, or go for a more basic UI with Xamarin Forms, if code sharing is more important.

React Native lets you share both business logic and UI. The business logic is written once for each platform and is executed on a different thread by using the same javascript engine that is used by the browser running on your phone. React renders to native UI elements over a JavaScript bridge. The end result will be an app with a native look and feel. As the language is the one from the web, and as the business logic (global state management, API calls, etc.) can also easily be shared with the accompanied web application, React Native is appealing for web developers and can certainly be a perfect fit for certain products.

Each of those frameworks has some drawbacks of course, be it in performance on some platforms, disappointing tools, or hard to customize. The Flutter team has tried to identify and improve all of these shortcomings. Their main focus is letting developers deliver beautiful, smooth apps at a high pace, with an awesome development experience. The main difference between Flutter and React Native (or Xamarin Forms), is that the UI is not rendered to native UI elements but by the Skia rendering engine. This means that your UI will look exactly the same no matter the platform. This leads to a faster development cycle for features, since you only have to create a single layout. If needed, Flutter still allows to have views that look native to each platform, all from the same codebase, within the same environment.

For a more in depth look at what the Flutter architecture looks like, check out the architecture overview that the Flutter team has made available here.

What makes Flutter also stand out are its basic elements, called widgets. In fact, everything in Flutter is a widget, not only your UI elements. In the end your entire application is just a tree of widgets. There are widgets responsible for layout, animation, positioning but also for building other widgets for example. While you can create your own widgets of course, Flutter already provides you with a large set of pre-built widgets to use. This way, you can quickly develop a good-looking application, targeting android devices with the Material Design widgets, or iOS devices with the Cupertino-style widgets.

Were there announcements during the keynote that you didn’t expect?

The most unexpected part, was the way that the team presented Flutter as a portable UI toolkit. Also there were already some steps made by the community to make Flutter work on more than just Android and iOS, but to see that initiative presented on the main stage of the event is a game changer, they’re even taking it one step further and including web applications.

Other than that, there were some interesting announcements. The Flare tool will be a welcome asset. It allows the designer to create complex animations, that can be easily imported in a Flutter application and manipulated in code. This makes us think a lot of Lottie animations, so this is a very welcome addition.

We were also pleasantly surprised with the announcement of the partnership with Square. They have already delivered some very useful libraries for other languages, so also for Flutter they will be a great asset for sure. Less surprising was the partnership with Nevercode. While we haven’t used it ourselves yet, there are quite a few articles relating to Nevercode and Flutter, so this was a logical evolution.

One of the biggest drawbacks of Flutter that we saw, was that there was no support yet for integrated webviews or Google Maps. With the plugins that were released just a few days ago, they also got rid of that hurdle, so for us, there’s really no reason left not to start using Flutter.

Why did they go with Dart as a programming language?

This is a question that is asked often. There is also a section about this on their FAQ page. In short, Dart just satisfied all of their needs. In practice, Dart is not that different of any other modern object-oriented language. If you know Swift, Kotlin, or Javascript, you’ll get to know Dart in no time. Dart also allows the code to be compiled in different ways. That’s how Flutter can both support JIT (just-in-time) compilation needed for the stateful hot reload, and AOT (ahead-of-time) compilation for more performant release builds.

No, Flutter will probably not be the Holy Grail as some people might claim, but it is definitely a framework to keep an eye on. Now that Flutter is not in beta anymore, it can mature and we can build up more experience with it. As Bram and Yves said: there’s really no reason left not to start using Flutter!

‍