Why Flutter is not your choice for building the best app in the world?
In this post, I will share with you my humble opinion about using Flutter in large, scalable and maintainable projects. There is a lot of articles that are hyping Flutter. Unfortunately, there is not many articles about the possible problems that you can have. Here you can find few words against.
Why I would not recommend Flutter for building the best app in the world? With Flutter we will have to be more careful on every aspect of the development. It is still not mature enough. Of course, the title is a bite, I think that Flutter is an overall a good tool, but for things that it was created. It’s great when time to market is the most important factor, however it is not so great when you need a long term, bulletproof solution. This is also a very community driven solution, and like in all that cases, it doesn’t have one owner who is responsible for the quality.
If we would like to use Flutter as a separate module in a huge app, we would need to maintain Flutter developers and deal with all overheads that Flutter brings – size, memory and startup time.
What is good in Flutter:
- Build once run everywhere (Android, iOS, soon Web)
- Performance is close to native
- You have access to a set of widgets implementing Material Design and iOS-style
- Low entry threshold
- Dart is simple language
- Apps looks very beautiful
- Static typing language (but can be dynamic typing also!)
- Hot reload
- Great when time to market is key factor
- Great when you have small team
- Great for MVP’s
- Great when your app is only a CRUD (create, read, update, and delete)
What is bad in Flutter:
- Second-class citizen in the mobile — this is not native, and it’s not developed by platform team. For iOS it’s obvious, but even in Google, Android and Flutter are two separate teams. Flutter needs to catch up after native.
- Second-class citizen in the IDE — it doesn’t have its own, dedicated IDE, smart completion doesn’t work, limitation of Dart-SDK
https://github.com/dart-lang/sdk/issues/40262 - It needs to deliver its own engine with every app — adds size, memory, startup overhead
- There is still work for the native developers in Kotlin and Swift
- Dart is too simple/immature language when you compare it to Kotlin or Swift
- Dart can be a dynamic typed language, which can be very dangerous!
- Static typing isn’t so static — you can omit return type, and IDE will not know about your type.
- No static metaprogramming (https://github.com/dart-lang/language/issues/1482)
- Troublesome code generation
- Sometimes you can observe UI “Janks” — can be because of your code or engine bug
- You have to be careful when it comes to performance:
https://flutter.dev/docs/perf/faq
https://flutter.dev/docs/perf/rendering/best-practices - Limited WebView support
- Some bugs are not fixed for a long time
https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc - You have to use community driven solutions. Their maturity is variety, and sometimes they don’t have long-term support for both platforms. Some plugins are just dead, and you need them badly.
- No straightforward way to create different flavours for using different environments etc. You need to use workarounds.
https://flutter.dev/docs/deployment/flavors
https://medium.com/@salvatoregiordanoo/flavoring-flutter-392aaa875f36 - Lack of mature JSON serialization
https://flutter.dev/docs/development/data-and-backend/json#code-generation - Not very good in case of media playing
- Not very good at using specific platform features
- “Will Apple reject my Flutter app? We can’t speak for Apple, but their App Store contains many apps built with framework technologies such as Flutter.“ – quote from Flutter FAQ
- We cannot treat Google as a guarantee of long term support. Google already closed a lot of projects.
https://gcemetery.co/
My Flutter questions:
1. When you lost benefits of common code in Flutter?
You lost most of the benefits when you have platform specific UI or you need deep system level integration.
2. What possible problems do you see?
Read the Cons sections.
3. How looks the community cooperation?
The community is growing and very helpful, however you can stick with a dead plugin, and you will need to write everything on your own. Also, some bugs stays for a long time.
4. Do we have a good documentation?
On the one hand, Google provided great documentation.
On the other hand, Google left a lot of things for the community, and you have to choose some of the workarounds that they prepared.
On the third hand, not all important documentation are ready:
https://flutter.dev/docs/perf/memory
5. Do we need to use external dependencies when we are working in Flutter? Do they look mature?
One more time – community driven. Some solutions are mature, some not. Some are available only for the one platform, some of them have limited functionality, some have bugs, some are dead.
6. Is there any known security issues?
Security similar to the native. Most things are handled by third-party plugins, sometimes you have to write native, platform specific code. There is lack of very specific tools like RASP Runtime application self-protection).
https://joshuamdeguzman.com/10-tips-to-secure-your-flutter-mobile-apps/
https://www.linkedin.com/pulse/mobile-app-security-native-vs-flutter-rick-wu/
https://medium.com/flutter-community/how-to-make-a-flutter-app-with-high-security-880ef0aa54da
7. How big is the entry threshold?
Flutter is created as a solution with the lowest possible entry threshold. It has tutorials how to quick start as an Android, iOS or Web developer.
8. Are there things we should be particularly aware of? How easy is it to break things?
Yes, a lot of them, and it’s easy to break things down. Flutter is easy to learn, but gives a lot of power in the hands of the developer. With great power, comes great responsibility. You have to be aware about performance issues, watch out for widgets that changes state, watch out for the static typing in the Dart language.
https://flutter.dev/docs/perf/faq
https://flutter.dev/docs/perf/rendering/best-practices
9. What is the tooling support – IDE, CI/CD, automatic code review tools, etc?
Overall, it’s far from perfect.
IDE is not mature, as for Kotlin or Swift, smart completion doesn’t work.
CI/CD is supported, mostly through the fastlane or solutions like bitrise.
Automatic code review tools don’t support it by default (there are plugins, community tools).
The is also no official guidelines about architecture or code structure.
https://flutter.dev/docs/deployment/cd
https://community.sonarsource.com/t/support-for-dart/13555/24
https://github.com/insideapp-oss/sonar-flutter
https://github.com/dart-code-checker/dart-code-metrics
10. How looks testing?
We have good testing tools. It’s close to native, but needs some extra effort to run on multiple modules.
https://flutter.dev/docs/testing
11. What is the effort to integrate this into existing complex app?
It’s good enough when Flutter is a closed feature that doesn’t need to communicate back and forth with the native part.
https://flutter.dev/docs/development/add-to-app
12. Can we easily integrate multiple modules/framework that uses Flutter in existing app?
We can, but not easily. It’s still an experimental feature. The start of each separate Flutter view will have startup overhead to start the Flutter engine.
Note: Support for adding multiple instances of Flutter became available as of Flutter 2.0.0. Use at your own risk since stability or performance issues, and API changes are still possible.
https://flutter.dev/docs/development/add-to-app/multiple-flutters
13. What is the impact on a build time/app size/startup time?
Flutter uses hot reload during development, so it speed-ups development.
For release build it will have normally compiled.
App size is bigger than native one. Also, Flutter app uses more memory.
Flutter need some initial time to start up its engine.
Flutter team is working on all above things, however they can’t be as good as in native app, because Flutter needs the own run environment.
https://flutter.dev/docs/resources/faq#how-big-is-the-flutter-engine
Great performance test done some time ago:
https://medium.com/swlh/flutter-vs-react-native-vs-native-deep-performance-comparison-990b90c11433
14. What is the impact on the existing app architecture?
We would need to design Flutter features as separate ones, so the impact would be low.
15. How looks the open issues? How they are resolved? Are there any issues that are hanging for a longer time?
The community is very engaged, however there are some issues that hang for a long time, even critical ones which crash the app. Sometimes you can hit the wall and can’t solve the problem.
https://github.com/flutter/flutter/issues?q=is%3Aissue+is%3Aopen+sort%3Acomments-desc
16. How Flutter communicates with existing App?
Flutter uses asynchronous channels to communicate with native part.
You should invoke all native code on the main thread.
https://flutter.dev/docs/development/platform-integration/platform-channels
17. How looks the support for the newest Google/Apple changes/guidelines?
It is quite good, however Google have to always catch up after new OS features. Especially for iOS, which is not owned by Google. It doesn’t use any native components, all things are created from scratch.
18. How Flutter handles animations?
Flutter is created with beautiful design in mind, and it handles animations well. It can have bigger problems with really heavy animations.
Great performance test done some time ago:
https://medium.com/swlh/flutter-vs-react-native-vs-native-deep-performance-comparison-990b90c11433
Other articles that you should read to be aware of possible problems when you will be working with Flutter.
https://vvsevolodovich.dev/10-things-that-are-wrong-with-flutter/
https://medium.com/asos-techblog/flutter-vs-react-native-for-ios-android-app-development-c41b4e038db9
https://betterprogramming.pub/why-flutter-isnt-the-next-big-thing-e268488521f4
About The Author
Artur Latoszewski
On a mission to build great mobile products. Android Dev with a passion for business and management. Mobile phones are remote controls of our society. Let's do them right! Clean architecture fanatic, SOLID believer, Kotlin fanboy.
Leave a Reply to John Cancel reply
This site uses Akismet to reduce spam. Learn how your comment data is processed.
Well, that was an exhaustive list. Thank you for putting it all together as architectural type decisions require “exhaustive” thinking unfortunately.
Thank you John! That was after my review if we should go for Flutter or not.
After a while, I think that I should expand this list.
The huge problem is when you have Flutter next to Native, and you have Database. Flutter has its own thread, I assume that your native has its own thread, and the database can be accessed only from one thread. This is a straight way to crash.
Thanks for the interesting article.
I note though, that every short coming and “question” you have in your article would still be perfectly valid if you simply did a search and replace for “Flutter” with “Jetpack Compose” or “SwiftUI” (or even to a lesser extent with the legacy Android or iOS frameworks).
Certainly every tool has its strengths and weaknesses, but that needs to be in the context of the specific requirements of each project, which unfortunately really cannot be done in the sort of general article you have written here.
@Maksim you have right, but this is the role of the Architect to choose proper architecture for the proper use case.
The main goal of my article was to show as much as possible problems that can occur with the flutter.
I’ve documented my thinking process when I was thinking if I should choose Flutter as a technology for the project in which I would like to deliver the best possible quality without compromises.