Does Flutter have enough marketshare, to make this the next best investment of time and energy?
If your use case is "typical" like 90% of the apps out there, I think there's no reason to invest in native anymore (I did native Android a while back, so I can't comment if you're coming from iOS). Flutter has very strong developer productivity (such as "press Cmd+\ to auto-reload"), wide array of plugins (now with official Firebase plugins). Heck, somebody wrote a "Visual Basic" for Flutter (https://flutterflow.io/) using Flutter.
The real problem with Flutter is it's tendency to attract bottom-of-the-barrel cheapskate customers. I don't want to double down on my earlier mistakes and box myself into lower-paid 10% of already lower-paid (compared to iOS) Android development market.
OK let's put a constraint: multiplatform. Take Flutter out of the equation, then what do we have: RN, Ionic, Kotlin Multiplatform... what else?
- RN, Ionic: errr I'm still having nightmares reading JS/TS code
- Kotlin Multiplatform: not stable yet?
Qt can even be deployed to embedded systems if that's your jam.
Most apps are budget constrained - doing 2x native over flutter budget doesn't get you 15% better UX. It probably doesn't even give you two working apps in the budget. And getting to them you're still likely 2x bugs and worse UX because of the time spent redeveloping common shit.
If you're not budget constrained, have a team that can execute better UX without flutter, and this matters to your app - go for native. But there's so many scenarios where it doesn't.
Dual native also gets you better portability to new platforms branching off of iOS and Android — for example most native iOS apps can be turned into suitable AR apps for visionOS with two clicks and it does most of the UI adaptations required for you. Flutter won’t be able to do that for years if ever.
It's not productivity, it's cost. If an app costs twice as much to build for "20% better UX" then that's ridiculous. You can release earlier and spend half the difference on bugfixes/polish/additional features based on what you see in the wild.
1. Common libraries (api clients) need to be built for all 3-runtimes (swift, kotlin, and dart).
2. Flutter runtimes increases the app size (539kb vs 4,700kb [0]), which is a problem for apps that are already too big.
[0] - https://medium.com/android-news/comparing-apk-sizes-a0eb37bb...
The users literally don't have the space to install apps, so they don't.
I would be curious to know how many apps with a 1M+ downloads use these frameworks.
I can imagine many big / popular apps switch to native once they have the resources to do so but start off with cross-platform.
Not really. Startups looking to keep costs as low as possible tell themselves this and there’s a lot of advice out there from people who will tell you the same, but it’s very rare. If you are tempted to go with the cheap option and plan on switching once you have the budget, make your peace with the fact you will probably be stuck with the cheap option forever.
6% of the top ranked apps use Flutter.
React Native: 5.43% of apps (4.18% of installs) Flutter: 4.22% of apps (1.39% of installs)
It's clear from the ratio of apps to installs that React Native is used by apps that are on average 3x more popular, but that isn't really a sign that the framework is less viable, just that more of the most popular apps are were written using something else - and I'd speculate that in many cases those apps predated Flutter.
I actually find it more interesting that the number of apps written with Flutter compared to React Native is fairly similar. To me, that suggests that Flutter is gaining ground rapidly, because that very much wasn't the case when I first starting using Flutter on my hobby project a few years back.
In any case, your 25% target seems unrealistic for any framework [1]. Unless your takeaway is also that React Native is not a viable target until it too hits 25%.
[1] I'm discounting Kotlin from these stats as it's not a framework [2], and similarly I don't understand why they counted the Android components as a framework.
[2] Actually, I'm surprised Kotlin is this way down in the charts... If native code is now more popular than Kotlin, that could cause compatibility issues now some phone manufacturers are starting to experiment with RISC-V instead of Arm.
GCP support in Flutter is excellent. You know… because Google…
Now if you’re talking about ecosystems, package managers, CI/CD…