Kotlin Multiplatform in 2027: Is It Finally Worth Trying?

Every year or so, someone in your group chat sends "okay THIS time Kotlin Multiplatform is ready." And for a few years running, the honest answer was: kind of, but the iOS story still had rough edges. If you're sketching a 2027 roadmap right now, the calculus really has changed — and the thing worth knowing is that it changed a while ago, not last week.

Below is the friendly, unhyped version: what actually works today, what still bites, and how KMP stacks up against Flutter, React Native, and just-write-it-twice. If you've read our breakdown of web apps vs native apps, this is that same fit-first framework applied to KMP specifically.

What actually changed

Two things stopped being asterisks:

• KMP itself is stable. Not "stable-ish, watch for compiler regressions." Actually stable, and has been since 2023, on Android, iOS, and JVM. K2 stopped being "the new compiler" and just became Kotlin; the current stable release is 2.4.10, out in July 2026.
• Compose Multiplatform on iOS grew up. The milestone was Compose Multiplatform 1.8.0 in May 2025, when Compose for iOS was declared stable and production-ready. Everything since has been polish: 1.10 (January 2026) made Compose Hot Reload stable and bundled by default, unified @Preview into commonMain, and brought Navigation 3 to non-Android targets. 1.11 (May 2026) flipped concurrent rendering on by default on iOS. 1.12 is in RC as we write this.

The ecosystem caught up too. Ktor for networking and SQLDelight for persistence are boring-in-a-good-way now. Coroutines, serialization, KSP2, DI — all fine. You can build a real app with real libraries without stitching together beta releases. Tooling settled down in a less glamorous way: JetBrains abandoned its standalone Fleet-based KMP IDE in early 2025 and put the effort into IntelliJ IDEA and Android Studio instead. That's the supported path now, and Google backs KMP on Android officially, so you're not betting on a side project.

Where each target actually stands

The most useful thing to internalize before a spike is that "KMP" is not one maturity level. It's a stack of them:

Read that table as a scope filter. Phone apps: green. Desktop companion: green. A web build from the same codebase: possible, but you're an early adopter. Watch app: wait.

The pitch was never "write once, run everywhere." It's "share the boring 80% and stay native for the interesting 20%." That's a much better deal.

Who's actually shipping this in production?

You don't have to be an early adopter to try KMP anymore. JetBrains keeps a public case-study list, and it stopped being hand-wavy a while back:

• McDonald's, Forbes, Cash App, Bitkey by Block, Duolingo, Bolt, Philips, VMware, Wrike, Meetup and Quizlet all share business logic across iOS and Android.
• Google ships KMP inside Workspace apps, including Google Docs.
• Instabee is the interesting one for small teams: they migrated their Android app's logic and UI and brought it to iOS with Compose Multiplatform.
• Booking.com published a detailed write-up of two production KMP use cases in June 2026, worth reading before your own spike.

"Big companies use it" is not itself a reason to pick a stack — but it does mean the landmines got mapped by people with deeper pockets than yours.

What still bites

KMP is good, not magic. In no particular order, the things that still make you sigh:

• iOS build times. Kotlin/Native plus Xcode is not fast. It has genuinely improved — K2 and successive Kotlin/Native release-build optimizations moved the baseline, and JetBrains showed further build and memory gains at KotlinConf in May 2026 — but a cold clean build still tests your patience. "Grab a coffee" is still a thing.
• Swift interop is the real rough edge. Swift export — the feature that gives you idiomatic Swift APIs instead of Objective-C-flavored headers — is still Alpha, still opt-in, and still doesn't do cross-language inheritance or real generics. Production apps go through the Objective-C interop path. This is the biggest thing to watch as you plan into 2027.
• Native module bindings. When you need a Swift-only API — a specific StoreKit flow, a fresh HealthKit permission, a vendor SDK — you're writing Swift and bridging. It's fine, but budget for it.
• Compose UI is close, not identical. Scrolling, haptics, and default look-and-feel are near-native on iOS, and 1.11 added an experimental native text-input path. But you still can't fully replicate the newest SwiftUI polish — the Liquid Glass refresh landing with iOS 27 this fall, some system animations — without native bits.
• Smaller ecosystem than Flutter or React Native. Libraries exist, but the third-party pool is shallower. You will occasionally need to write your own binding.

KMP vs Flutter vs React Native vs Native

For the honest comparison, here's how the four realistic options actually feel to a small team right now:

If this table made you curious about the other side of the coin — Flutter vs React Native vs Native — the short version is that Flutter wins UI-heavy consumer work and React Native wins when your team already lives in TypeScript. And if you're still choosing which platform to launch on at all, start with iOS vs Android: where should you launch your first app?

When KMP is the right call for your 2027 roadmap

Green lights:

• Internal or B2B apps where the UI is functional, not flashy.
• Brand-consistent products that want the exact same look on both platforms.
• Teams already fluent in Kotlin, or Android-first shops that want to add iOS without hiring a second team.
• Products that expect to live for years — the "share the boring 80%" bet compounds over time.

Red lights:

• Game-adjacent apps or anything with heavy custom animation and gesture choreography.
• Teams already deep in Swift/SwiftUI shipping happily — there's no upside to disrupting that.
• Products that need to ship day-one support for the newest iOS-only capabilities. The iOS 27 Liquid Glass refresh arrives this fall and Apple is steering everyone onto it; if your differentiator is being first with that look, stay native.
• Roadmaps that depend on clean, idiomatic Swift APIs over your shared module. Swift export is coming, but it isn't here yet.

Where people go wrong (and when to call a pro)

If you'd like a hand designing the shared-module boundary, bridging the awkward iOS parts, or setting up CI so builds don't ruin the day — that's exactly the kind of work we do. Take a look at our services and tell us what you're building.

Frequently asked questions