Your web browser is out of date. Update your browser for more security, speed and the best experience on this site.

Update your browser
CapTech Home Page

Blog May 17, 2018

Google's New Cross Platform Tool: Flutter – What's The Catch?


At Google IO 2018, there was a lot of buzz about Google's relatively new framework, Flutter. Flutter is another tool meant for cross-platform mobile development - you may have heard of a few others such as Reactive Native, Xamarin, and PhoneGap. Flutter, unlike some of its competitors, seems to have an advantage since it's being supported by Google. CapTech took a deep dive into the world of Flutter to see if this is just another tool that falls short like so many others, or if it's a viable solution to be considered.

Brand First, Design Focused

One thing to keep in mind when considering the usage of Flutter, is that Flutter is built primarily to support applications with a "brand first" design. Meaning, its built to support applications that look and feel the same across Android and iOS. Flutter falls short for apps with designs that rely heavily on OS guidelines. While, Flutter does provide you the option of writing platform-specific code, doing so causes you to lose the advantages of using Flutter in the first place. If your application has a brand first design, and behaves and acts the same across platforms, this may not be a concern for you.

Larger App Sizes

Google noted in one of their talks at IO that for every 6MB added to your application, you lose 1% in downloads. To help solve that issue, Google did a lot of work to help developers keep their app sizes low. However, Flutter adds some overhead and apps come out of the box much larger than apps built natively. This is due to some of the core engines that are used to run a Flutter application. For example, a simple app with a single widget built in Flutter would be around 6MB - that is twice as large as what Android allows for Instant Apps and about 5MB larger than the same basic app built natively would be.

Largely Dependent Upon Packages

Working with third-party frameworks is a common practice in many enterprise applications. Most of these frameworks are built natively for both iOS and Android. With this in mind, unless the framework being used also has a Flutter package, it would be up to the application team to write native Android & iOS code to expose this framework to Flutter. Today, there are many packages created for and by Flutter to access native functions such as gesture features and device information, but Flutter does not intend on supporting every native Service and API by design. Instead, they provide a message system to allow developers to communicate with native code, which they would have to write themselves on the platform level. This means that Flutter developers would still need to be proficient in both iOS and Android or you would be largely dependent upon the packages made available for Flutter.

Dart & Native Code

Flutter developers work in Dart and can choose from a few different work environments including Android Studio or Visual Studio Code. Developers write their functional code and UI code all in Dart, often times in the same file. Flutter developers will primarily use Dart, but as I mentioned above there will be strong use cases where your developer has to write native code for Android and iOS. This means that your Flutter team will still need iOS(Swift/Objective C) and Android(Kotlin/Java) support on top of needing to know Dart. Flutter then compiles the Dart code natively in an "Ahead-Of-Time" compilation - meaning, unlike some other frameworks, there is no code interpreter.

Still In Beta

While Flutter is extremely polished and runs very well, it is still in beta and has a few bugs here and there. At the time of writing this blog, Flutter sits in version 0.4.4 with over 3k issues. While this seems large, Flutter in the past year has closed over 6k issues. Flutter is just not quite ready for the prime time yet.


There are a few things that Flutter just cannot do yet(remember it's still in beta) and some that Flutter never will be able to do by design.

  • Flutter doesn't use OEM widgets.
    • This is actually by design, but it does mean that if you want to use a new widget right when it's released you will either need to build your own or wait for Flutter to support it.
  • Background Work on iOS
    • Currently, background work to be performed when the app is not in use is not supported by iOS.
  • 3D and OpenGL development
    • Currently there is no support for 3D development. It is in the plans to expose a Flutter variant of this, but it's currently not supported.


While Flutter seems appealing and definitely is the most advanced cross-platform tool to date, it's still only suitable for specific use cases. Enterprise mobile applications would still need to rely heavily on iOS and Android developers to achieve all of their business needs. Smaller applications or even PoCs, however, could be a good fit for Flutter. Though Flutter can be a great way to get your feet wet in mobile development, you'll still get the greatest value tuning your mobile application solutions to your specific business problems.