Two Frameworks, One Misleading Question
“Should we build this in Flutter or Kotlin Multiplatform?”
The question has an assumption welded into it: that the two are competing for the same job. They aren’t.
Flutter hands you one codebase and paints every pixel itself. Kotlin Multiplatform hands you a shared logic layer and leaves the pixels to the platform, unless you deliberately opt into Compose Multiplatform for the interface too.
That’s not a feature difference. It’s a different theory of where cross-platform value actually comes from.
And it’s why we watch KMP a lot more carefully than the framework-of-the-month cycle usually justifies.
What Each One Actually Ships
Flutter compiles Dart and draws through its own rendering engine. Your button is a Flutter button on iOS and on Android, drawn by the same code, identical down to the animation curve.
Platform consistency comes for free. Platform feel is the thing you pay for.
Kotlin Multiplatform inverts that. Shared Kotlin compiles to JVM bytecode on Android and to a native binary on iOS through Kotlin/Native. What lives in the shared module is the unglamorous half of the app: HTTP clients, JSON parsing, offline sync, validation, pricing rules, the state machine nobody wants to write twice.
The screens stay native. Jetpack Compose on Android, SwiftUI on iOS.
So with Flutter, parity is free and nativeness is expensive. With KMP, nativeness is free and parity is the thing you work for. Everything else in this comparison falls out of that one line.
Worth saying plainly: the shared-logic layer is usually where the bugs that cost real money live. A rounding error in a discount calculation, written once, tested once, shipped to both platforms. That’s the pitch.
KMP vs Flutter vs React Native
| Kotlin Multiplatform | Flutter | React Native | |
|---|---|---|---|
| Build model | Shared Kotlin logic, native UI per platform. Shared UI is opt-in via Compose Multiplatform | One Dart codebase, own rendering engine paints every widget | One JS/TS codebase driving real platform widgets |
| What you share | Anything from a single logic module to logic plus the whole Compose UI. You choose the line | Effectively everything above the platform channel | UI and logic, with native modules for the gaps |
| Ecosystem maturity | Stable since 2023; Compose for iOS Stable since 2025; Compose for web still Beta. Library pool is the thinnest of the three | Deepest of the three. Large package registry, long vendor tail, Impeller finishing its Android rollout through 2026 | Broadest talent pool through React. Ecosystem is wide, and the New Architecture has been the only one since 0.82 in late 2025, with the legacy code still being stripped out behind it |
| Hiring reality | Any Android developer already writes the language. iOS people need convincing | Dart is a small language with a big framework. Flutter developers are plentiful and portable | Your existing React developers can ship mobile in weeks |
| When it wins | Existing native teams, long maintenance horizon, logic-heavy domain, ambitions beyond mobile | Design-led product, one small team, consistency beats platform convention | Your web team is your app team and the component patterns transfer |
No row in that table says “best.” That’s deliberate.
The Years KMP Spent Growing Up
Cross-platform tools earn trust slowly, and KMP has been earning it in public since well before most teams noticed.
JetBrains marked it Stable in November 2023. Google announced official support for sharing business logic with KMP between Android and iOS at I/O 2024, which mattered more than the version number did: it meant first-party Android libraries would stop being an Android-only proposition.
Then the interesting one. Compose Multiplatform for iOS reached Stable with the 1.8.0 release in 2025, with feature parity against Jetpack Compose for common cases, type-safe navigation, and VoiceOver support. Shared UI stopped being a demo.
The adoption curve moved with it. JetBrains’ Developer Ecosystem survey put KMP usage among its respondents at 18% in 2025, up from 7% the year before. That share comes out of a general sample of 24,534 developers, not a KMP-only one.
More than doubling in a year is the kind of number that usually comes with an asterisk. Here the asterisk is simply that it started small.
The production list is the part that changes our reading, though. Cash App, Quizlet at roughly 50 million monthly users, Forbes, Philips, Autodesk, Meetup, 9GAG. Those are not pilot projects with an escape hatch.
What Would Make Us Pick It
We don’t pick a stack because it’s interesting. We pick it because of what the client’s situation already looks like, which is the same framework we use for choosing a tech stack in 2026: team skills first, then deployment target, then data shape, then timeline.
Run that against KMP and four situations light up.
- There’s already an Android team. This is the big one. A shop with Kotlin people can adopt KMP without hiring anybody, because the shared module is just Kotlin they already write. Flutter, in the same shop, means introducing a language nobody uses in production.
- The domain is heavier than the interface. Insurance quoting, logistics routing, field-service scheduling, anything where the rules are the product. The UI is a thin shell over a thick engine, and the engine is exactly what KMP shares best.
- The app has to live for eight years. Native UI ages with the platform. A Flutter app’s look is pinned to the framework version you shipped, and catching up to a new iOS design language is your migration to do.
- Mobile isn’t the end of the story. Kotlin runs the backend too. A shared validation module used by the Android app, the iOS app and the Ktor service is a real thing you can build, not a slide.
That last one is the argument we find most interesting, and it’s structurally identical to the case for running TypeScript across your whole stack: one language, one mental model, one set of types crossing every boundary. Same logic, different territory. TypeScript owns the browser-to-Node axis; Kotlin owns the mobile-to-JVM one.
The Part Nobody Puts in the Comparison Posts
Framework comparisons are written as if the choice happens once, at the start, with a clean team and no legacy. The version we actually see is messier.
A typical case: a company has an Android app that works, an iOS app built two years later by a contractor, and a support queue full of tickets that only reproduce on one of them. The quoting logic disagrees between platforms because it was written twice by two people who never met.
The honest cost of fixing that with Flutter is two rewrites and a design freeze. The honest cost of fixing it with KMP is extracting one domain module, shipping it into the Android app first, then into the iOS app, without either app going dark.
That second path is unglamorous and slow. It also survives contact with a roadmap that has other things on it.
Which is the real reason our interest went up. Not benchmarks. Migration shape.
Set against that, a first KMP project carries an obvious tax: the build setup is fiddlier than a Flutter project, the Gradle configuration surprises people, and someone on the team has to learn what expect/actual means before the first sprint ends. Budget for that learning curve honestly, or it shows up later disguised as a velocity problem.
What Would Stop Us
Now the honest half.
The library situation is thinner, and it bites in boring places. Payments, maps, analytics SDKs, video: each one is a question of whether a KMP wrapper exists, whether it’s maintained by one person, or whether you write the expect/actual glue yourself. Flutter’s registry has a package for almost everything, and a decade of Stack Overflow answers behind it.
Second, the iOS developer experience is still the weak side. Swift interop has run through an Objective-C bridge, which leaks: Kotlin’s sealed classes, default arguments and coroutines all arrive in Swift looking less idiomatic than they should. Direct Swift export fixes this, and it’s moving from Alpha to Beta on the Kotlin roadmap published in August 2026.
Alpha to Beta. Not shipped.
Third, a team that is genuinely iOS-first will resist, and they’re not wrong to. Asking Swift developers to consume a generated framework and step into compiled Kotlin/Native frames from Xcode is a real tax, paid by the people who didn’t ask for the change. JetBrains knows it: better Xcode integration for the Kotlin/Native debugger sits on the same roadmap as Swift export.
Fourth, Compose Multiplatform for web is still Beta. If someone sells you “write once, run on mobile, desktop and browser,” check which of those four targets is carrying the Beta label.
And a fifth that has nothing to do with technology: can you hire for it? Flutter has a large, mobile, well-marketed talent pool. KMP’s pool is essentially “good Kotlin developers who are willing,” which is a smaller circle than the adoption numbers suggest.
So What Are We Actually Doing?
Not switching. Watching.
For a client with no mobile team and a design-led product on a tight timeline, Flutter is still the call, for the reasons we set out in when we choose Flutter over React Native and in the broader native versus cross-platform comparison. Nothing in KMP’s 2026 position changes that.
What has changed is the shape of the conversation for the other kind of client: the one with a working Android app, an iOS app drifting out of sync with it, and a domain model that has been implemented twice and disagrees with itself in three places. Two years ago the answer there was “rewrite both in Flutter” and everyone winced. Now there’s an answer that doesn’t throw away the native apps.
The thing we’re waiting on is Swift export reaching Stable. That single milestone converts KMP from “excellent for Android teams who also ship iOS” into “genuinely neutral between the two platforms,” and the difference between those two sentences is whether an iOS lead nods or folds their arms.
Until then, our read is this. KMP is the right answer for a narrower set of projects than its fans claim and a wider set than its 18% adoption figure suggests. If your shared logic is worth more than your shared pixels, it deserves a serious look.
If it’s the other way round, Flutter is still sitting right there.
Weighing a cross-platform decision you’ll have to live with for years? Let’s talk it through. We’ll look at your team, your domain and your timeline, and tell you honestly which side of this line you’re on.
