The Flutter project is built on a great vision — namely building apps for any device with one codebase, as conveniently as possible. Is Flutter finally the silver bullet we’ve all been hearing so much about, the one great platform to build all our apps and websites on? I doubt it, here’s why…
Please note that these are my personal opinions.
Some issues with using Flutter for creating your standard apps
One of Flutter’s selling points is that it renders the content pixel by pixel. This is a big responsibility for an app framework. This responsibility is also shared with game engines for instance, where both Flutter and game engines need to render the desired content and need to do so with good performance.
Let’s start with the desired content. In terms of design, Flutter has two starting points to offer, either the bootleg iOS design or the soulless Android look, i.e. pure Material design. Flutter has spent considerable amounts of time and focus on recreating both these designs when most Flutter projects really want their own unique look and feel. In practice, that means starting off with material design and customizing components to the desired look, while bringing the material feel. When using a material-based UI it often feels like breaking the fourth wall of good, unique design when those material design ripple effects or those material-branded animations show up (unless it’s Google’s app of course). This becomes a questionable design choice if you aren’t interested in material design or a bootleg iOS design. However, if that’s what you’re after, Flutter will be a fitting choice (in Flutter’s defense, it is a Google project and amazingly enough Google likes material design).
When it comes to performance, oh boy are there some bumps in the road. Flutter has and still is struggling with janks, lag, and other problems that worsen the user experience.
One of those ‘other problems’ is the issue of Flutter not being able to target the device’s native refresh rate. It’s as if Flutter at its core is hardcoded to run at 60FPS, even though the target platform is capable of frame-rates well beyond that. The new iPhones have brought some attention to this with their new ProMotion displays featuring dynamic refresh rates up to 120Hz. It doesn’t seem like there will be an easy solution anytime soon, exactly because Flutter ships their own rendering engine which manages what will render at which refresh rate. This refresh-rate issue isn’t only observable on mobile, it’s also found in Flutter desktop, and even Flutter web. Yes, you read that right, even on web! If you’ve got a higher refresh rate display, test it here and see how the feel of the site is instantly degraded in comparison to other sites. Some people respond to this issue with “well I don’t have a high refresh rate display so I don’t care”, and that is simply not a good enough argument in my opinion. If Flutter aims to be a framework delivering good UIs with good user experiences, native refresh rate is just as important as native resolution. If, however, Flutter aims to be ‘just good enough’, then it surely has succeeded. Although I really hope Flutter is aiming a bit higher than ‘just good enough’.
These issues show the problems that come with bringing your own rendering engine instead of relying on native, already implemented and familiar rendering.
So, should Flutter be ignored then?
No. As the title of this article says, I do have some doubts about Flutter, but also the hype around it. Yes, Flutter has some technical issues, and due to the fundamentals of the Flutter architecture, I think it should not be your default pick as an app framework. And for goodness sake don’t use Flutter to build your websites.
However, just because Flutter isn’t the magical silver bullet to base all your apps on, it’s still a useful tool. Here are some examples where I think Flutter has some potentially great use cases:
- You want a completely custom UI. Projects such as games, video editors, code editors, etc. could pick Flutter with ease.
- PoCs. If you want to create a working example as quickly as possible, and you don’t care how it looks or feels, Flutter would be an exceptional choice.
- If you have one requirement that goes beyond everything else: the need for one codebase to produce apps on iOS, Android, desktop, the web and potentially embedded. As discussed this will come with user experience as a cost, but the single requirement of one codebase is fulfilled.
As mentioned, game engines share a lot in common with Flutter, and you might notice that engines such as Unity could also be used for the same cases (although it probably wouldn’t be optimal). Would you use Unity for your standard apps beyond these special requirements cases? No, and perhaps the same applies to Flutter in some ways.
What’s the conclusion?
To sum it up, it seems Flutter has more cons than pros when it comes to building your standard app with standard requirements. Flutter has been hyped up to be this evangelical framework that will be the end of all others, but at the end of the day it’s just another tool to build apps, but with rather special requirements.
It will be cool to see how Flutter evolves in the future, and having another option for building apps is never wrong!
