For four parts I have dissected, compared, and categorized languages and frameworks. Now comes the part many people would rather read first, and which I deliberately saved for the end. Because if you want to know the answer, you first have to ask the right questions. Which framework wins depends entirely on what you are actually building, and with whom.
No Ranking, but a Clear Stance
I am not going to draw up a ranking here. Not because I have no opinion, but because a ranking is simply the wrong tool in this context. A multimeter measures voltage. An oscilloscope shows waveforms. Both are indispensable, neither is better. Anyone who works with comparisons like that in electronics knows: the tool follows the task, not the other way around.
Still, there are patterns that run through real-world practice, and I want to name them honestly here.
If I Start Alone or in a Small Team
For a solo project or a small team without strong prior experience in a particular language, I would reach for Flutter today. Development speed is high, the tooling is mature, Dart is quick to learn, and the result looks clean on both platforms. The community provides a package for almost every use case, and when something is missing, you usually find the answer faster than with other frameworks.
In my view, Flutter has grown from an exciting experiment into a solid production tool. Three years ago that was not yet the case.
If a Web Team Needs to Come on Board
React Native. No lengthy discussion. If you have a team that knows React and works with it every day, do not throw that knowledge away. The New Architecture has largely defused the old performance problems, TypeScript brings the necessary structure, and the ecosystem is simply enormous. Getting started is easy, the learning curve is gentle, and in practice that counts more than any benchmark.
If the App Has to Reach Deep into the System
Then there is no way around native development. Swift for iOS, Kotlin for Android, done. If you need AR features, complex audio processing, deep system integration, or maximum performance, do not even consider cross-platform. That is not a weakness of the frameworks. It is simply the reality of the platforms.
Here I speak from my own experience: AuraHarmony, my app for Solfeggio frequencies and binaural beats, is built on Kotlin and Jetpack Compose, because audio synthesis at that level demands native APIs that no cross-platform framework abstracts cleanly. I do not regret that decision for a moment.
If Kotlin Is Already a Given
Then Kotlin Multiplatform deserves a serious look. Write the business logic once, use it on both platforms: that is no longer a dream but everyday practice in a growing number of teams. Compose Multiplatform is maturing visibly, and anyone who has already internalized the concepts of Jetpack Compose will feel at home immediately. KMP is my personal bet for the coming years, not as a replacement for the other options but as the logical next step for teams already rooted in the Kotlin world.
For AuraHarmony, KMP is the next step I am concretely planning: porting the audio logic and database layer to iOS without rewriting the entire app. That is exactly what KMP is made for.
What Holds True Across All Decisions
Whichever approach you choose, a few things remain true. First: the language is rarely the real problem. Architecture, team structure, and clear requirements weigh more heavily than whether you write Dart or JavaScript. Second: no framework fixes bad software design. A poorly structured Flutter project is just as unmaintainable as a poorly structured native app. Third: the community around a framework is at least as important as the framework itself. If you are on your own when a problem hits, you made the wrong choice, no matter how elegant the syntax.
My Personal Conclusion
If I started from scratch today, with no existing project, no team, no prior experience: I would choose Flutter. Fast, consistent, production-ready. If I want to extend my existing Android project: KMP. If I need to bring a web team on board: React Native. And if the app needs low-level features that do not tolerate abstraction: native, without compromise.
That is not a contradictory conclusion. It is the most honest one I can give, because mobile development simply does not come in one size. The best decision is the one that fits your own context, not the one being celebrated most loudly on Twitter right now.
This series ends here, but the topic keeps evolving. KMP is maturing, Flutter is growing, and somewhere in a Berlin startup someone is working on the framework we will all be talking about in three years. I will stay on it, and I will report back.