Flutter – Our Journey with the Cross-Platform Framework

Flutter Framework, developed by Google shows its strengths in the fields where others Frameworks struggled. It took a different approach for integration with native systems and kept the best of what developers wanted - passion for coding.

About Flutter

Flutter is a cross-platform UI toolkit that is designed to allow code reuse across operating systems such as iOS and Android, while also allowing applications to interface directly with underlying platform services. The goal is to enable developers to deliver high-performance apps that feel natural on different platforms, embracing differences where they exist while sharing as much code as possible.1

It’s powered by the same hardware - accelerated 2D graphics library that underpins Chrome and Android: Skia.2

The beginning

We, at MWAY, always try to find the best solutions to the specified requirements requested by customer. Being deeply involved in always-developing enterprise world, it was (and still is) our goal to bring the best quality and performance to the solution.

The trial

Since we already had experience with previous “hybrid” generations of Frameworks and tools (Ionicframework, Cordova, Phonegapp, Generator-M, etc.), we knew exactly what minimum requirements the next promising Framework should achieve.

This contained in a list is:

  • The framework should produce an app that should behave and look exactly the same as the native app does
  • The framework should give the best possible developer-experience, with as little issues as possible
  • The framework should be compatible with our CI/CD systems and the end-result should be the same as what developers are experiencing
  • The framework should behave exactly the same on both (iOS and Android) systems
  • The framework should have the ability to use additional resources/assets without any issues (Fonts, SVG, Charts, GraphQL or similar, etc.)
  • The framework should produce the solution, which should perform faster than our current solutions on all devices (read: close-to-native-performance)
  • The framework should be multi-cross-platform meaning at least iOS and Android (web was a plus)

Before going into any evaluation, we’ve had to understand the basics of how Flutter works.3

Technology comparison*

To see how good the Framework performs, it is usually not enough to just create the basic project - at least not in enterprise world. Our Flutter acceptance came from two different use-cases:

  1. Creating a basic use-case with loading data from file, saving to database, presenting it in list-view. For this, we’ve developed and used exactly the same files when comparing Flutter and Ionic solutions. Unneeded plugins and modules were completely removed, --release flag was used, several iOS and Android devices (and versions) were used. The devices were ranging between entry-level to flagships models and from the newest to the oldest. To keep it realistic, we’ve saw around 10% performance increase overall.

  2. Using the framework in an PoC application for which basic checks for plugins were made. Other than that, for the first time developers were greeted with the Dart language on which Flutter is based on. The first feedback from the developers perspective was extraordinary: “enjoyable & fun”.

Trials end

We were convinced that Flutter is moving into the right direction. However, there were still ups and downs from the framework itself. These were:

Pros 👍🏻

  • Awesome beginner developers' experience
  • CLI and IDE extensions just work and help a-lot with development
  • Hot reload is one of the best implementations we’ve used
  • async/await works exactly as you would expect
  • Crazy amount of logic patterns to use (MVP, BloC, Provider, Redux, etc.)
  • RXDart, InheritedWidgets, FutureBuilders, StreamBuilders, ValueNotifiers, setState- widgets - different approaches for getting to the same goal

Cons 👎🏻

  • Forces you to be organized (take care of your workspace)
  • Dart is a new programming language
  • JSON parsing
  • ENUM support
  • Breakpoints between asynchronous calls will result in a non-responsive app or weird exception
  • If you know RxJS doesn’t instantly mean you will know RxDart
  • Http behaviour / extending basic functionality (http-interceptors for example)
  • It is up to you how you will integrate the logic (state management was a big thing at that time, too)
  • The i18n and ARPs language files (meaning all other known implementation example being JSON files have to be handled by your own Handler)
  • No web support at that time, even though some kind of “Project Hummingbird” was being expected

Current status

Back to the present time, Flutter has been updated quite a-lot in the past two years. And so was our knowledge and expertise in Flutter framework. We’ve now built more than 10 enterprise apps based on Flutter. We have never regretted this decision. And now, as the framework is being optimized and updated, we are happy to say that first iterations of Flutter for Web conversions have been made.

We have also noticed the community is ever-expanding and the interest is continuously growing. Therefore, we have also decided to create a Flutter Meetup Stuttgart group, which has been a blast from the start on.

Flutter Meetup Stuttgart

That being said, the last thing you should always take into consideration (as we did also) is the capacity of community involvement and the pace of the Issues progression (Flutter issues on official Github Repo). Most of the issues reported will get any kind of feedback in the first 24 hours.

Comparing the demographic interest between two of our most used frameworks now should provide you with a good picture of evolvement:

Google Trends comparison between Flutter and Ionicframework

However is everything really so bright as it looks like?

If you are carefully following all the news and annual reports from the Flutter team, you will see the future looks bright. However, one part for which we still keep our Ionic/Angular Frameworks is the web. Even though, our first tests and Flutter apps also were ported to the web, it is still too early to make a complete switch. One of the downsides being the performance and deprecation of old browsers support (Internet Explorer 11). You will laugh, however, we are talking about enterprise solutions and with that, a long term commitment and support. Not every company has an urge to update everything to the latest and greatest version. Keep that mind.

Another thing, which now looks like a “funny joke” is actually state management. Two years ago, the whole World Wide Web was full of articles regarding Flutter and how great it is, but actually just showing the “Counter App” and nothing else. This issue escalated really quickly into the massive amount of articles regarding which state management approach is the best for your app.

The future

If the progress that we saw in the past two years will keep up to the goals of the Flutter team, then we are quite sure we’ll see a decline of usability of other previous frameworks that we’ve used. Still, nothing should be taken as granted and its always a good bet to check the competition. Everything can change in a matter of months… as it already did change in the past years.

We will continue believing in Flutter - being the best optimized and performed Framework we have used so far.





  1. Flutter architectural overview
  2. Flutter Github
  3. A deeply detailed but never definitive guide to mobile development architecture