Flutter Pros and Cons for Hybrid Mobile Development
In a previous article, we explained the differences, the advantages and the disadvantages of using native vs. hybrid technologies for developing you next mobile application. To recap, both native and hybrid solutions are worthwhile: it all depends on your project. If you want the most flexibility as to what your application can do, for it to feel like a first-party citizen of its platform, and want to be able to benefit from the latest OS features, you should go native. It comes with the least downsides, but at the cost of longer development time. On the other hand, if you’re on a tight budget and don’t mind sacrificing on a few platform-specific features, you could go hybrid.
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 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
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
#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.