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 February 27, 2019

A Review of Google's Flutter 1.0

Alan Shih

Introduction

Last year, Google generated hype around its new cross-platform technology, Flutter. Captech previously covered the topic and I strongly recommend reading Google's New Cross Platform Tool: Flutter - What's the Catch? before continuing as this content builds on the previous post. Flutter left beta in December. What has changed and how viable is Flutter for a production application?

At the time of beta 0.4.4, there were over 3K open and 6K closed issues. Google closed an additional 6K issue over the span of nine months. While impressive, the number of open issues has ballooned to over 4K. With its popularity on the rise, Google seems to have trouble keeping up with Flutter issues, even as they introduce new features.

Flutter Benefits Recap

  • Free and open source
  • Based on an easy to learn, object-oriented programming language, Dart.
  • Reusable and modular widgets
  • Reactive and responds to state changes
  • One code for two platforms
  • Hot reloading support

Updates

The major changes since 0.4.4 include:

  • Tweaks to Android user interface elements to conform better to Material design specifications
  • Improved debugging
  • Added iOS-styled interface elements
  • Dark SDK updated to Dart 2
  • Better support for iOS
  • Build optimizations
  • Bug fixes and performance improvements

Previous Concerns

Larger App Sizes

Flutter applications remain significantly larger than native applications. The flutter engine has been optimized where the minimum Flutter application size is ~4.06 MB, down from the previous ~6 MB. The iOS IPA has remained at ~10.8 MB due to compression loss from encrypted binaries.

Dependent Upon Packages

Google currently has a limited set of 32 first party plugins where nearly half of them are for supporting Firebase and Google services. To access many native functions, the integration of third-party plugins or custom built packages is necessary.

Flutter doesn’t use OEM Widgets

No, but Flutter’s widget catalog is expanding to minimize the issue. Other widgets are in their plugins such as Google Maps, camera, video player, and web views.

  • Advantage
    • The concept behind not using OEM widgets is to produce higher quality widgets are motion-rich. By using a single framework and set of libraries for the UI, app development and maintenance costs are lower.
  • Disadvantage
    • Even though Google advocates a “brand first” design, Flutter applications are Android-biased. If you did want to give the application a native iOS feel, it would require adding conditionals to swap out nodes in the widget tree. Due to the differing design philosophies of iOS and Android, a separate widget tree is sometimes necessary.
    • New and updated UI elements on iOS and Android will not be reflected until Flutter updates its counterpart.

However, Flutter is working to bring native view integration through the use of PlatformViews, but will largely be reserved for more complex native views. (e.g. Google Maps)

Background Work on iOS

Background support is still under development. Support for background operation for iOS plugins is slated to be fixed in March.

3D and OpenGL Support

No support with plans to expose an optimized 3D API in the future.

Additional Concerns

Quality of Plugins

  • The quality of plugins available is widely varied where many are not well tested
  • Some plugins only support a single OS
  • Having to rely on third-party developers is an additional layer of complication that could have been solved using native APIs that are thoroughly battle-tested
  • Some plugins are at higher risk of failure as they are third party plugins that rely on native third-party frameworks
  • Many of the plugin developers have created their plugin to meet specific use-cases. That means they typically have the bare minimum in customization and functionality required to meet the original developer’s needs. Any additional requirements beyond the plugin’s capability require forking or creating your own plugin

Programmatic UI

  • Being able to create the UI in the .dart file makes building and wiring the interface a fast process
  • There is little separation between UI construction and business logic which negatively impacts maintainability as complexity rises

Future of Flutter

Only a few months out of beta, the long-term support for Dart and Flutter is unknown. Google has a history of quickly pivoting onto new initiatives while abandoning existing products. We can only hope that Flutter gains proper traction among the cross-platform and native developer communities to warrant continued support.

Conclusion

Building applications that are simple and don’t require deeper integration is a breeze in Flutter. However, Flutter 1.0 is not entirely stable with the potential of breaking updates in the future. With limited first-party plugins where some are still in alpha, resorting to third-party plugins is virtually unavoidable.

Developing a beautiful and feature-rich application would likely require developing your own plugins. This means that your Flutter team will still need to have proficient skills in native iOS / Android. The additional overhead of developing and maintaining the plugins would negate much of the benefits of Flutter. With that in mind, Flutter continues to be suitable for specific use-cases.

When should I use Flutter?

  • Looking to prove a concept and get it to market to as many people and as quickly as possible
  • Enterprise applications that are not concerned with a consistent or rich UI

While it is evident Flutter is suffering from growing pains, keep it on your radar as it continues to rapidly mature.