Some approaches you smile at first and then use in production a year later. For me, Kotlin Multiplatform belongs in that category. What JetBrains has built over the past few years is not yet another cross-platform promise with a shiny surface and a brittle foundation. It is a well-thought-out middle ground that differs fundamentally from Flutter and React Native, and that is exactly why it deserves an article of its own.
The Core Idea: Share What Is Worth Sharing
Kotlin Multiplatform, KMP for short, does not pursue a one-size-fits-all solution. The framework does not force you to manage the entire app in a single shared codebase. Instead, it focuses on what genuinely makes sense across platforms: the business logic. Network calls, database access, data models, validation logic, all of that moves into a shared Kotlin module. The UI stays native: Swift on iOS, Jetpack Compose on Android.
That sounds like a compromise, but it is actually the opposite. Instead of delivering 80 percent everywhere, KMP delivers 100 percent in the right places and lets each platform shine where it does best.
Compose Multiplatform: When the UI Joins In After All
JetBrains has since gone one step further. Compose Multiplatform extends Jetpack Compose, Google's declarative UI framework for Android, to iOS, desktop, and web. That brings KMP closer to Flutter without copying its rendering approach. On Android, Compose runs natively; on iOS, Compose Multiplatform relies on its own rendering layer, similar to Flutter but based on a technology Android developers already know and appreciate.
So if you already work with Jetpack Compose on Android, you do not have to learn a new language or internalize a new paradigm. The concepts are the same: composables, state, side effects. That lowers the barrier to entry considerably, and that is not a marketing argument but everyday practice.
Still Under Construction, but What Kind of Construction Site?
Honesty is called for here: not every target platform is equally far along. Kotlin Multiplatform itself is stable, and Compose Multiplatform is stable for Android, iOS, and desktop. The web target (Wasm), on the other hand, still carries the "beta" label, which means API changes are possible and some features are still missing. And even on the stable platforms, debugging on iOS occasionally requires patience.
But, and this is the decisive point, it is a construction site with a clearly recognizable plan and visible progress. JetBrains ships regularly, the community is growing, and the first companies already use KMP in production: Netflix, for example, uses KMP for shared logic in its mobile studio apps, and Touchlab helps organizations adopt and scale KMP. A construction site that people are already happily living in is something quite different from one where the shell is still waiting for the structural engineer.
KMP vs. Flutter vs. React Native: Who Is Actually Competing with Whom?
The question inevitably comes up, and the answer may surprise you. KMP does not really compete with Flutter or React Native, at least not directly. Flutter replaces the entire native UI, React Native abstracts it. KMP complements it. If you have an existing Android team and want to add iOS without rewriting the entire codebase, KMP is an option that Flutter simply cannot offer.
From an engineering perspective, this is a familiar pattern: you do not pick the most powerful tool, you pick the most appropriate one. An oscilloscope does not replace a logic analyzer. Both have their place on the bench.
What Convinces Me Personally
I built AuraHarmony, my app for Solfeggio frequencies and binaural beats, in Kotlin and Jetpack Compose. The idea of porting parts of that codebase to iOS without starting from scratch is remarkably attractive. KMP would make exactly that possible: the audio logic, the database layer, the settings management could all be shared while the UI stays native on both platforms.
That is not a theoretical scenario. It is the path I am seriously considering for the next stage of the app, and it is precisely why KMP currently occupies me more than any other framework in this series.
Conclusion for Part 4
Kotlin Multiplatform is not a cure-all, and Compose Multiplatform is not yet where it will be in two years. But the direction is right, the foundation is solid, and the approach is more honest than many a promise from the cross-platform world. If you are already at home in the Kotlin world, KMP should be on your radar, not as an experiment but as a serious strategic option.
Part 5 brings the conclusion: what would I choose today, and why?
Sources
- Supported platforms – Kotlin Multiplatform and Compose Multiplatform stability (kotlinlang.org)
- Kotlin Multiplatform Case Studies – Netflix (kotlinlang.org)