As you might know, we provide services for building mobile apps in native languages (Swift, Kotlin, Java and ObjectiveC) for both major platforms as well as cross-platform development with Flutter (Dart language). Several times in the discussion with native apps clients we've been hearing same question: why haven't we built our solution with Flutter instead of building it with two separated native languages? And the answer is always "because Flutter isn't good for your project". So, looks like it's time for writing down a bit on a topic what Flutter is good for - and what for it isn't.
What Flutter is good for and what for it is not.
A bit of a history and on a magic behind the scenes.
When you go to Flutter project home you find following short description “Flutter is Google’s UI toolkit for building beautiful, natively compiled applications for mobile, web, and desktop from a single codebase” and this is true: Flutter allows you to build beautiful and smooth UIs, animation performing at 60 fps (twice as fast as ReactNative, BTW!), isolates bring multithreading on a plate so performance of a properly written Flutter app is really comparable with the properly written native app.
Let's check if we can build any UI: what are the most commonly used UI elements you see in the modern apps? Buttons, lists and tables with interactive cells, sliders, charts etc. All of these are available and easily customizable. Building beautiful modern UIs, following principals of Material Design or even more and more popular skeuomorphism in Flutter is absolutely possible, check out some UIs we've built for our clients with Flutter:
So, let's list the cases when using Flutter saves you time and money:
When using Flutter saves you time and money.
Go for it if:
- You have a system with relatively light-weight mobile client, like social network, employee app, event app. Flutter is extremely good with nice and smooth UI building, REST consumption and other standard tasks.
- Your mobile app is not the key point of a product but more like a marketing tool: let's say you're you lunching a new brand of a bottled water and mobile app is needed as an advertisement tool, to increase brand awareness and product presence. You have way more things to think about and to invest resources into beside the two native mobile applications.
- You developing a POC for a product pitch. If the product and idea does not include low level mobile OS APIs (like sound or video editing, BLE communicating between devices etc.) - Flutter is the perfect choice.
If you don't know yet, some of huge companies', like Alibaba, mobile clients are made with Flutter. This speaks for itself.
Sounds like a magic bullet, doesn't it? Well, let's continue our research.
Let's not forget about this is a framework, with it's own language and it's own project structure, build processes etc. Let's imagine we need some popular third party library, like Google Maps, be used in a project. Obviously, we can't just install pods for iOS or import the library with Gradle for Android and write the piece of a code to make it visible in a project in platform-specific files - they are re-generated each time from the Flutter code so our changes be lost. We need to check if there is a Flutter module for Google Maps available. Likely for us, Flutter has a wide and growing community and the more it becomes popular - the more often libraries vendors consider it a must to offer Flutter-oriented build of their components. As you may find in Internet there are a lot of Flutter modules for a most popular components: modules for Google Maps, FireBase, Twillio, various social networks integrations etc.
Next question we should ask ourselves - what if I need some less popular component to be integrated into my Flutter mobile app? Let's take a LiveChat as an example (we're taking it from our experience, of course). Nice , subscription-based, system even can be named premium-quality. Let's imagine you pay for this service already - and you want to use it in your Flutter app. But, unfortunately, they do not provide the Flutter SDK (at least on the moment of we've been working with it they didn't). How you should proceed? There are only two ways: ask vendor to build and ship and support the Flutter SDK for their product (and we actively encourage all mobile libraries vendors to do so! Future is calling and future is Flutter!), which can take a while - they have for sure list of higher priority tasks and calls like bugfixing and supporting libraries they already ship and sell, building new library without any immediate money flow will be prioritized much lower, of course. Or you can order a custom Flutter wrapper module development from some software developers like us. We've build the LiveChat wrapper for one of our clients, fixed Google Captcha for another etc. But - this is custom software development already. Developer, who can do this, shall be not only excellent Flutter developer, he or she also shall be good with both iOS and Android development. So, this can be painful and in some cases even can break you plans. Sometimes we recommend replacing some services and solutions developing the Flutter application just because of cost of implementing replacement solution is dramatically less. To illustrate it: there is a very nice geo-locating and mapping solution on a market called "Here". They don't have officially supported Flutter SDK, at least on the moment we needed it they did't. After estimating costs of building one client decided that as long as this system is the keystone of their solution and they can't replace Here with Google Maps or OpenStreet Map - they better develop two native apps separately then invest into one-time usage Flutter module.
It sound like we've reached a point of a discussion trade offs we face developing with Flutter, isn't it? Let's dive into a topic
Trade offs we face developing with Flutter.
Let's summarize what we already know about possible trade offs and systematize what we know about them:
- Firstly, do not be mystified by the seeming simplicity: building two versions of an app, one for iOS and one for Android, on a single Flutter codebase isn't two times faster and two times cheaper than building two totally separated apps with native languages. Flutter developer needs to test his work on two platforms, sometimes finds himself in a situation when module he chose to use works fine with one planform - but works with issues on another (here we need to mention WebView and SoftKeyboard - these known for described issue, many Flutter-nubies broke their teethes on them). From our experience if we take A as an Android app build cost and I as an iOS version for the same app, F (Flutter) is not equal to (A + I)/2, it's more like 2*(A + I)/3.
- If your solution involves non-widely used component, API or service - the probability of developers would't find Flutter-made module for it is worth to mention. Do the research before count on it, reality might correct your plans.
- Development cost for custom Flutter modules and libraries is very high because developer(s) who can do it shall be good with all three Flutter, iOS and Android. If you're tight on budget, sometimes it's surprisedly more cost efficient to go with native development.
Now, when we know about what Flutter is good for (apps with modern beautiful UIs and more or less standard functionality, like news aggregators, food ordering and delivery apps, social networks clients, wrappers around simple web sites allowing user to open site in a WebView inside the app etc.) and in what cases usage of Flutter is a trade off (apps using non-standard components and specific APIs, like chats, video calls, maps etc.) let's go to the next stop: when using Flutter is a really bad idea.
When Flutter is a really bad idea?
First of all, I'd like to emphasize that everything in this section is a private opinion, sometimes based on experience and sometimes - on a theoretical thoughts. As long as these limitations based mostly on platform limitations and the general hybrid approach restrictions, unfortunately, they hardly be ever resolved in Flutter. Fairly saying, same applies not to Flutter only but to all and every hybrid solution ever been and ever be on a market.
One of niches we at A5 Mobile Development working in is IoT. Mobile applications in this field massively use BLE, bite protocols and sensors data. Working with low-level OS APIs is a must for this kind of apps, and of course we've tried to use Flutter for this. And out experience taught us this is not a good idea. Meaning building UIs for IoT systems like Ajax Solutions - perfect task for Flutter. But just because on this case Flutter is only dealing with UI representation and REST API/Push Notifications. All the IoT 'magic' happens between installed sensors and IoT Wifi Hub system is built around. When it goes on using sensors, BLE, raw bites, sockets and other low level APIs on mobile device - Flutter fails. Its hybrid nature makes it work in a sort of sandbox and in-system low level tools not available in Flutter directly. Only way to somehow get into it is writing a wrapper around native libraries and using it. This leads to performance degenerating below the acceptable level and development cost boosting to the stars.
Another one fields where Flutter is not applicable is sound and video processing. Working with rough bites, applying filters etc. usually done with C-written natively compiled libraries and very different from platform to platform. Any hybrid solution here is only adding more wrapping layers so not improving things.
Let's have a list of bad ideas now:
- Do not use Flutter if your mobile client needs to deal with collecting sensors data or working with BLE.
- Do not use Flutter if you need to access low level system APIs like sound/video streaming and processing. Masquerade and Instagram-like apps with Flutter experience is 99% about to fail your expectations. OCR on the client side with Flutter is a bad idea too. It will only work if image recognition and processing done on a serverside.
- Do not use Flutter if your application uses Augmented Reality: Apple's and Google's approaches and APIs are very different, native libraries provided by them are hardware optimized. Wrapping native libs in a Flutter module to use it on both platforms is a very bad idea, use native!
- Machine Learning things on the client side of a Flutter app is also a road to hell, due to the same reasons as AR. Google and Apple did an amazing job on squeezing all possible out of a mobile device, stay on the shoulders of a giants.
- VoIP and secured messaging over the Flutter are also a bad idea, as long as these need low level OS APIs be involved.
The Conclusion
Use Flutter for: apps with modern beautiful UIs and more or less standard functionality, like news aggregators, food ordering and delivery apps, social networks clients, wrappers around simple web sites allowing user to open site in a WebView inside the app etc.
Have a second thought if your app is using non-standard components and specific APIs, like chats, video calls, maps etc.
Better go for native development if you're building an app processing video or audio, using BLE or sensors data, using machine learning or image recognition on a client side.
Hope now we know much more about where Flutter is applicable and where it is not. If your have some ideas on a new app and have concerns if Flutter is a way to go - drop us a message and we gladly help you to decide.
As our experience grows and Flutter framework improves every day, the lists and even the ideas in article may be corrected or totally changed with time. Thank you for reading this and stay tuned for updates!