Flutter Pros and Cons for Hybrid Mobile Development

Once you have weighed the pros and cons and decided that a hybrid technology makes more sense for your project, we’d now like to explain why we think that Flutter is the framework to go for. Initially released in 2017, it’s one of the most recent hybrid solutions for mobile apps. But despite its relative youth, it is feature rich and sports several key advantages that elected it as our go-to hybrid framework at Atipik. Here’s why.

The different hybrid technologies for your mobile app

Before ending up with Flutter as our preferred hybrid stack, we’ve tried several other technologies over the years. Despite their respective merits, they all had downsides that were strong enough for us to avoid investing too much time and energy into them. Here’s a quick retrospective of those we’ve tried and what we think about them.

The oldest we’ve tried : Ionic Framework

Ionic Framework was released in 2013 and is the oldest of the frameworks we tried. It provides an HTML, CSS and JavaScript environment on top of mobile operating systems, acting akin to a browser. It comes bundled with libraries for accessing native APIs of the underlying devices, as well as libraries of UI components emulating standard mobile controls. While it was originally built on top of AngularJS, it is now based on Web Components, giving the developer the freedom to use the web framework of their choice.

Ionic comes with two main advantages:

• Web developers will be able to get up and going very quickly, whatever the framework,
• It’s a mature technology with good documentation and community support.

But it has drawbacks that should not be disregarded:

• It often provides a user experience that feels at odds with the underlying platform conventions: weird transition timings, visual anomalies, etc.
• It is not as performant compared to the other hybrid technologies we tried.

React Native, requires a lot of maintenance

React Native was created and released in 2015 by Meta (originally Facebook). It is an offspring of Facebook’s React framework targeted at mobile platforms. Similarly to Ionic, it provides a web-like development environment. The main difference comes from the fact that React Native components are actually backed by native views of the underlying platform (UIView on iOS, and View on Android). Like its parent project, it is also an application architecture framework based on the Unidirectional Data Flow (aka Redux) model.

It has most of the advantages of Ionic, as well as the following two:

• It has a big developer community, and therefore third-party resources are easily available (forums, Stack Overflow, etc..),
• It can be made to feel more native than Ionic by using as many components as possible backed by native system controls and navigation controllers.

But unfortunately, we have experienced one severe drawback to React Native:

• The maintenance effort is substantial, due to the rate at which the main React Native framework breaks backwards compatibility, and because of the large number of indirect dependencies.

Kotlin Multiplatform Mobile, promising, but too young

The first alpha version of Kotlin Multiplatform Mobile was released in August 2020 by JetBrains, the company that developed the Kotlin language and the Android Studio IDE. This cross-platform solution is an intermediate approach between pure hybrid and native technologies. Compared to the previous contenders, KMM is not a framework but a build system that allows developers to write code in Kotlin that natively targets each platform. This allows sharing one codebase for non-UI logic, while still keeping the flexibility of implementing the user interface of each platform with the native APIs.

This vastly different architecture comes with two major advantages:

• It allows developing apps without any compromise on feature set or quality as developers can directly access the native APIs of each platform,
• You can start integrating KMM into existing projects, which allows a smooth and gradual move to KMM without rewriting the application from scratch.

Despite those substantial advantages, we have noted the following drawbacks:

• It is a young technology, still in Alpha, with limited documentation, few dedicated libraries and a rather small community,
• The build and development process is still fragile, hopping between Android Studio and Xcode.

It’s too early for KMM to be a production-ready solution, but it shows promise as being able to replace native development when the project requires it, without any significant drawbacks.

Flutter, our feedback and opinion

In February 2022, Flutter will be five years old. Similarly to React Native, it provides an environment and framework for developing hybrid applications using a declarative syntax. But it does so using Dart, a language very similar to JavaScript developed by Google, Flutter’s first and main contributor. Despite being more recent than React Native and Ionic, it has gained a lot of interest and traction recently. This is reflected in its evaluation on Google Trends and Stack Overflow Trends below:

Our First Experience with Flutter

When we were tasked with developing a mobile application for both iOS and Android for the University of Geneva to allow cafeteria staff to scan student QR codes for reduced lunch prices, in under two weeks, we decided this was the perfect opportunity to try our hands at Flutter.

The application consists of a small number of screens but needed to integrate a QR scanning functionality, which is a very platform-specific feature to implement. We also wanted to continue developing using a Redux style architecture, like we do on our other projects. Thanks to Flutter’s growing popularity, and its large number of first and third-party libraries, we found quality libraries for all our needs.

Two weeks later, we had two functioning applications on the iOS and Android stores that have since been used to scan tens of thousands of QR codes in production without any major issues. Let’s see what we liked and disliked with our time using Flutter.

Flutter Pros for Hybrid App Development

#1 Development Environment Quality

The first thing that strikes while working with Flutter is the quality of its development environment. You notice it straight away during Flutter’s setup when using the flutter doctor command line tool. It checks that Flutter and all its necessary third-party tools and dependencies (the Android SDK, Xcode, Chrome, Android Studio, VSCode) are installed and up to date. It also checks that all connected devices are ready for debugging. And if anything is not as expected, it will provide detail information on how to fix it.

#2 Android Studio and VSCode Plugins

Furthermore, Flutter provides full-featured plugins for Android Studio and VSCode that will enhance those IDEs to be able to build, test, run and debug Flutter apps on all supported platforms. It also comes with a tool called Flutter DevTools that allows inspecting running Flutter applications when debugging. Flutter also has a hot-reload feature similar to other web-inspired hybrid technologies that worked flawlessly for us. All in all, the Flutter team has sweated the details so that the experience of developing for Flutter is as smooth as possible.

#3 First-party Documentation

This attention to detail also shows in the quality of the first-party documentation, which is both extensive and well written. It contains instructions for setting up the development environment, tutorials and sample projects, as well as guides on many diverse topics about development, testing, debugging, performance analysis and deployment. Throughout the development and deployment of our QR scanning application, we found many answers to our questions in there.

#4 Good Backwards Compatibility

Coming from a past experience with React Native, where backwards compatibility is often broken, causing major maintenance issues, we were pleased to notice that Flutter has a small history of breaking changes (in only six releases) and a strict compatibility policy. Moreover, the base SDK has no external dependencies, further reducing the risk of maintenance issues. For comparison, React Native has more than a dozen third-party dependencies.

#5 A Large Community

Despite being relatively recent compared to other hybrid technologies, Flutter already has a big community (as can be guessed from the Google and Stack Overflow trends above), which translates into a large amount of quality third-party packages. For example, we easily found a package to scan QR codes using iOS and Android native APIs. If it had not been available, we would have lost a lot of time implementing that feature on both platforms.

Flutter Cons for your Hybride App

#1 Having to Learn Dart

The first obstacle we hit when developing our Flutter application was Dart. Despite the Google-developed language being similar to JavaScript, it is still different enough that it took us some time to get up to speed with it. And we still have only scratched its surface: it is definitely more feature-rich and less simple(1) than JavaScript. As Dart is not widely used outside of Flutter, developers learning Flutter are learning a new language at the same time as a new framework, making for a steep learning curve.

#2 Platform parity

One of Flutter’s strongest advantage, and also its biggest weakness, is that it does not use native interface elements and controls, like React Native does. Instead, Google has reimplemented each platform’s controls on top of its own rendering engine (see the Material Components and Cupertino widgets). This allows Flutter to be truly independent of each platform’s underlying interface layer, which is great for the framework’s stability. But it can also be problematic when a project heavily depends on native controls: the re-implementations can never be perfectly equivalent. For example, if a new version of iOS changes native components, like tweaking the look of tab bars (as was the case in iOS 15), or introducing a new gesture for going back in navigation stacks (as they did a few years back), the Flutter re-implementation of those interface elements will not gain those changes automatically. The Flutter application will look at odds next to a native application.

#3 Google Owned

The final shadow on our assessment of Flutter has nothing to do with the framework’s merits, but with its stewardship. Despite Flutter and Dart being Open Source projects, Google employees are still their majority contributors. If Google decides to drop all work on them tomorrow, like they have been known for in the past, it will have a dramatic impact on Flutter. This is not likely to happen, but it is a risk we need to accept when using it.

So, Should you Use Flutter for your App ?

Thanks to the quality of its development environment, its documentation, its community, its library ecosystem, as well as its regard for backward compatibility, we can say that Flutter seems to be the right candidate for future hybrid projects at Atipik. Our experience with the development of the application for the University of Geneva confirms it: we were able to provide a very good user experience and good performance without the framework ever coming in our way.

But it’s not the end of native development at Atipik. Some projects still require the native interface elements and controls. And we sometimes need the flexibility that only the platform APIs offer us. However, once the choice of a hybrid solution is made for a project, we are now confident in using Flutter.

Flutter is still a young mobile development solution, so we'll have to take into account our long-term feedback to be able to definitively designate it as our reference hybrid framework at Atipik.

Footnotes

(1) The term simple is used here to mean that JavaScript has less features, is easier to get started with. One might argue that JavaScript is not simple to master though, as some of its corner cases and undefined behaviours are notoriously tricky.