Reasons not to Build Mobile App on Flutter Framework
According to LinkedIn, Flutter mobile development is the fastest-growing skill among developers and according to the StackOverflow survey about the Most Loved Other Frameworks, Libraries, and Tools — it is in the top three favorite frameworks in 2019. We also did not stand aside and not only decided to try mastering the new product, but even managed to carry out a project and send it to production!
First of all, it should be mentioned that our company dealt with native development only. The interest in cross-development was only educational, and we did not dare to use it in commercial projects.
(Editor’s note: due to the lack of extended expertise, the opinion described below cannot thus be considered absolute truth.)
Nevertheless, our Android team was interested in the fact that the company, developing our favorite mobile OS, offered its own solution. It meant we could not help trying it out. Besides, mastering it with native development experience behind our backs was quite painless, with our competitors it was the other way.
So what interesting things does Flutter offer along with other frameworks? The first thing it can really boast is UI building. Due to its own rendering engine, which renders all elements without using the tools built into the OS SDK the performance noticeably increases.
To say it differently, instead of interpreting the conditional button’s code into the native code for each platform (like the other frameworks do), Flutter framework undertakes the ambitious task of rendering everything by its own accurately simulating the behavior of the native interface elements (taking into account the animations, state, etc.) This significantly increases the speed of rendering compared to other approaches, and also allows building really complex screens without drawdowns on FPS. Also, the box solution provides many ready-to-use UI elements from the guidelines of both Material Design and iOS, which can be almost completely customized to meet your needs.
It should also be mentioned that a reactive UI design approach is used and as a result, the entire application is built into a tree of the so-called «widgets», which makes it easier not only to manage the state of one screen but the application as a whole.
Another unconditional plus is the work with Flutter animations. Simple conversions can be made in just a few lines of code thanks to special widgets for layout changes animation, and the above mentioned reactive approach makes their usage even more convenient:
In such a way Flutter becomes a perfect tool for building a graphic interface on both popular platforms at a time. But no application can do with a good design only, it should contain business logic as well.
The «reactive» architectural patterns are used to the fullest in Flutter Redux, Scoped Model, BLoC, and some others are among them. There are generally no problems here. However, we chose BLoC, more traditional for the community. It allowed us to apply the Clean Architecture approach without any problems. In such a way we separated the design code of the application from its business logic (which is very useful for a cross-platform project). Everything is quite good in terms of working with the network — a couple of libraries for working with Http are offered, and our choice fell on Dio among them. It, by the way, very much resembles Retrofit2 generally accepted in the Android community. There are also libraries for storing the app’s system data (Shared Preferences in Android, NSUserDefaults in iOS).
For the business data, there is a port SQLite (it’s certainly not Realm or Room, but at least something). There are bridges for using a camera, GPS and much more.
However, we do not have the heart at present to call this work stable and ready for usage in production. For example, we encountered a problem when OOM happens during recording videos on iOS, sometimes the first couple of frames are simply black. Also, due to the fact that the framework is rather young, there is no wide variety of libraries yet.
The attention should also be drawn to the number of repository issues at Github:
Certainly, that aside, Flutter has its drawbacks as well. They are characterized to all the cross-platform solutions:
- The necessity to write a native code did not disappear (the so-called bridges) since the necessary library is often missing or lacks functionality. The scenario may even be more pessimistic: everything works properly, but you need to add an add-on, which is not provided by the solution. As a result, you need to craft your own solution at the expense of time.
- The delays in app adaptation to the new OS versions. The fresh example is the color of the bar in iOS 13. A month has passed after the operating system release, however, no official version has been provided yet.
- More problems with unpopular device manufacturers (Android-related).
- A very attentive user can still find the differences from native behavior (the Ripple animation which is displayed when a user hits on clickable elements of the list, cards or background in Flutter is noticeably different).
- The developer is totally powerless if the bug has crept into the system itself.
To wrap it up:
In case you need a prototype to test a business idea, and the logic does not suppose «squeezing all the juices» out of the device’s capabilities, the application has a fairly simple logic (typical client-server interaction) but has a non-standard design — then Flutter is an excellent choice. You will get a single code base, simplicity of changes and excellent high-speed response. However, it is worth mentioning that making such products more complicated will lead to greater cost and time compared with the app development for each OS separately.
For complex solutions, which require the interaction with various device modules, native development should still be chosen.
