Why Flutter Isn’t the Next Big Thing

Flutter is a cool technology, but it‘s not going to fly. Here’s why.

I’ve noticed quite a few articles recently promoting Flutter as the “next big thing.” Several have even explained in detail how Flutter is going to replace React Native as the leading cross-platform technology of choice.

It’s not.

I’ve stuck my toes into Flutter’s clear but cold waters, and in my opinion, it suffers from several critical issues.

Note that this article has generated a lot of passionate comments from the Flutter community, both pro and con. I strongly suggest you read the article and then read the comments section below for points and counter-points.

It’s Not React Native

You can’t discuss cross-platform technologies without discussing React Native.

React Native is popular because a lot of people believe the hype and think that their front-end JavaScript developers can create first-class apps. They can’t, of course, but that doesn’t stop them from trying.

The problem is that many companies already have JavaScript developers. And all too often, the JavaScript folk will tell management, “Yep, we can do that in half the time.”

And as I pointed out, they can’t. Mostly because while it’s true you can get 80% of the app up and running quickly once you get past the learning curve, 80% of the actual time spent will lie in tweaking the app to look and run correctly on each individual platform.

Speaking of individual platforms…

It’s Not Native

Flutter’s Skia rendering engine ensures that your app only mimics a native look and feel. It may compile to native code but it’s not using native buttons, fields, toggles, scrollbars, tableviews, or other interface or navigation elements.

Apple and Google tweak and update those interface elements and their behavior on almost every release. As such, any app that ignores them will always lag behind.

Further, if a bug appears in Flutter on iOS, you’re going to have to wait for Google to get around to fixing it.

And speaking of iOS…

Second-Class Citizenship

I should note that I came at Flutter from an iOS perspective, and Flutter definitely makes iOS feel like a second-class citizen.

Flutter is very much an Android-first development environment, down to its fundamental reliance on Android’s Material Design guidelines. That’s the default look-and-feel.

So if you want to create something out-of-the-box that looks like an Android app and behaves like an Android app that’s great, otherwise… not so much.

Further, iOS development is expanding to many platforms within the Apple ecosystem (watchOS, tvOS, iPadOS, macOS) and as such Flutter only gets you so far.

Of course, you can get around part of that problem that by using Cupertino widgets, but…

You Still Have to Write Your Application Twice

As I just pointed out, Android supplies both Cupertino and Material widgets.

That’s cool, but it basically means if you want your application to appear native (which React Native allows, by the way), you still have to use the right widget set for the job. And this may mean writing some portions of your interface twice.

Not to mention that you may also have to restructure portions of your app accordingly for each platform in order to maintain platform look and feel (navigation inside tab bars as opposed to tab bars inside navigation, etc.).

Yes, you can reuse business logic, but I don’t think that quite makes up for having to write, test, and debug user interface issues and problems on both platforms. And speaking of that…

Debugging

Flutter is an application model and rendering engine running on top of the native operating system frameworks and services. Or to put it another way, it’s another layer on top of the existing layers.

When you do something in Flutter and it works, it can feel like the greatest thing since sliced bread.

When it doesn’t work, however… you can spend a lot of time trying to determine just where the fault lies. Your code? Flutter? The system? Third-party interface code you brought in to do some simple task because you don’t understand the underlying OS?

Debugging such things can be a major time sink.

It’s Not HTML

A few people have also mentioned in the comments that Flutter is available for the web, and as such you get “another” platform for free.

And yes, you can use Flutter for the web… although it’s still very much a beta technology and even Google doesn’t recommend it for most use cases.

Not every HTML scenario is ideally suited for Flutter at this time. For example, text-rich flow-based content such as blog articles benefit from the document-centric model that the web is built around, rather than the app-centric services that a UI framework like Flutter can deliver.

So yes, if you want to do some data visualization, make an online tool like a car configurator, or do some sort of embedded chart (again, Google recommended use cases) feel free.

Then again, didn’t we just kick some other heavy non-HTML-based app-rendering technology off the internet?

Support Is Negligible

While it is trending upwards, Flutter support and documentation is nowhere near that one can find for native application development on iOS or Android.

Want articles, books, videos, and courses devoted to Swift? Java? Kotlin? Cocoa? There are tons of them out there.

Need help on Stack Overflow? Almost anything you can think to ask has already been asked and answered.

With Flutter? Not so much.

This is reinforced by a point from the comments:

But the support issues alone are abysmal, especially on Android (dependency hell that rivals mid-90s and early 00s “DLL hell” on Windows).

Flutter’s Lifetime Is Questionable

Google notoriously runs hot and cold on technologies. It’s undeniable. And if Google ever thinks that Flutter isn’t going to pay off, it could be dropped like a hot potato.

Google’s pushing Flutter but at the same time they’re also pushing Jetpack Compose on Kotlin and even the Kotlin Native Common module for cross-platform support.

Not to mention that Apple is also pushing their version of a next-generation declarative development technology: SwiftUI. While not directly comparable in that it doesn’t allow the creation of Android apps, SwiftUI does let developers utilize their skills on all of Apple’s platforms: iOS, ipadOS, macOS, watchOS, and tvOS.

If both technologies do what they’re expected to do and both dramatically reduce the time it takes to develop native applications… that leaves Flutter with… what advantage, exactly?

Watch Your Language

One of the biggest drawbacks to Flutter is Dart, its implementation language.

Dart is one of the languages you can use if you’re running Google’s web or back-end hosting environments. And that’s pretty much it. This means that if you spend the time to learn Dart for Flutter, there’s a good chance that the only thing you’re ever going to be able to use your hard-won experience on is Flutter.

The latter point is probably the hardest one to deal with. I mean, if I wanted to become a mobile developer, I’d probably be learning Swift or Kotlin, as both are modern languages and there’s actually a major job market out there for both of them.

With Dart? Not so much.

Strictly speaking Dart isn’t that hard to learn, but that’s primarily because it is a simple language. As another commenter points out:

After learning Swift and Kotlin, Dart feels like a step back. It lacks many features available in other modern languages. Its type system isn’t great. It seems like the designer(s) had an “easy for the JS crowd” design objective. Dart is also very rough around the edges in a Javascript-like way, while Swift and Kotlin feel polished, mature and complete in all the important details.

Dart’s lack of market penetration means that should you need more Dart developers on your team, you’re probably not going to find them. Which in turn means you’re going to have to grow them on your own. That can be done, but you’re still paying for them to ramp up on your dime.

Finally, remember that at some point you’re probably going to hit the limitations of the framework (or need to target additional platforms) and then you’re going need to drop down and do some sort of native development anyway.

In which case, you’re still going to need to learn Swift and Kotlin.

Clients Don’t Want It

We’ve pushed Flutter to clients a couple of times as a possible solution and clients have resisted the notion — especially in favor of attempting to use their in-house JavaScript developers, as demonstrated in my first example.

But rest assured: Pretty much all of the other issues I’ve listed above were also mentioned.

Bottom Line: Flutter Is a Niche Technology

All of the above may lead you to believe that Flutter may not be the best choice for your project.

And that’s not true at all.

You just have to recognize its limitations.

In my opinion, Flutter is best suited for a small internal development team that needs to quickly create a proof-of-concept app that’s fundamentally non-native in appearance and design.

An example might be a kids game or app that’s graphically unique and decidedly non-native in appearance. In that case, it doesn’t really matter that Flutter doesn’t exactly mimic the experience of iOS and Android. It also lets you off the writing-interface-twice hook I mentioned above.

Oh, and you also need a team that doesn’t mind learning an entirely new platform and language to do so.

So… yeah.

Flutter’s a cool technology, but in most cases, it’s simply not going to fly.

Again, this article is an opinion. You’re welcome to disagree with me and leave your counter-arguments in the comments section below. (In fact, several of those points have made their way back into the article.)

Also note that I am not endorsing React Native. React suffers from many of the same issues and then piles some significant performance penalties on top of them.

Finally, and just for the record: I’m not saying that there isn’t a use case for Flutter. But like everything else in the known universe, there are tradeoffs and known limitations and in the end you have to to decide if you and your organization are willing to place long-term bets on this specific technology.

Thanks for reading.