At the end of my Flutter experiment, I arrived at a very straight-forward and convincing conclusion:

I wrote nicer, more maintainable code that runs on both iOS and Android. It also took considerably less time and fewer lines of code to do so.

One of the best parts was not having to deal with things like fragments, the SupportCompatFragmentManagerCompat, and preserving and manually managing state in a tedious, error-prone way. It’s just so much less frustrating than Android development…no more waiting 30 seconds for “Instant Reload” to change the font-size of a TextView. No more XML-Layouts. No more findViewById (I know that Butterknife, Databinding, Kotlin-Extensions exist, but you get my point). No more redundant boilerplate code — just results.

Once both apps were more or less on the same page in terms of features, I was curious to see what the difference in lines of code was. How does one repository compare to the other one? (Quick disclaimer: I haven’t integrated persistent storage in the Flutter app yet, and the code base of the original app is quite messy). Let’s compare the code using Cloc, and for the sake of simplicity, let’s just look at the Java and XML files on Android, and the Dart files for the Flutter app (this does not include third party libraries, which would probably increase the metrics for Android significantly).

Native Android in Java:

Flutter:

To break this down, let’s compare the file count first:

Android: 179 (.java and .xml)

Flutter: 31 (.dart)

Wow! And concerning lines of code we have:

Android: 12176

Flutter: 1735

That’s crazy! I was expecting the Flutter app to have maybe half the amount of code of the Android app, but 85% less? That actually blew me away. But when you start thinking about it, it makes a lot of sense: since all the layouts, backgrounds, icons, etc. need to be specified in XML, but then still need to be hooked up to the app using Java/Kotlin code, of course there’s gonna be a ton of code. With Flutter, on the other hand, you can do all of that at once, while also binding the values to the UI. And you can do it all without dealing with the shortcomings of Android’s data-binding, like setting listeners or dealing with generated binding code. I realized then just how cumbersome it is to build such basic things on Android. Why should we write the same code for things like Fragment/Activity arguments, adapters, state management and recovery, over and over again, when it can be so simple?

With Flutter, you focus on building your product and your product only. The SDK feels like a help and not a burden.

Of course, this is just the beginning of Flutter, as it’s still in Beta and not yet at the level of maturity that Android is at. Still, by comparison, it feels like Android might have reached its limits, and we may soon write our Android apps in Flutter. There are still some things that need to be worked out, but overall, the future is looking bright for Flutter; we already have great tooling with Plugins for Android Studio, VS Code and IntelliJ, profilers and view inspection tools, and more tools will come. This all leads me to believe that Flutter is more than just another cross-platform framework, but the beginning of something bigger — the beginning of a new era of app development.

And Flutter could go far beyond the realms of Android and iOS; if you’ve been following the rumor mill, you may have heard that Google is working on a new operating system named Fuchsia. As it turns out, Fuchsia’s UI is being built using Flutter.