.jpg)
I spent weeks investigating Kotlin Multiplatform (KMP) with Compose Multiplatform. I built a full production-like e-commerce app called Storium to find out where this technology actually stands. The findings are honest: the foundation is impressive, 92% shared code is real, but the ecosystem around it has gaps that matter.
This is not a framework comparison from reading documentation. It comes from building authentication, offline caching, search and filtering, localization, encrypted storage, theming, and shared navigation into a single app, then measuring what worked and what required platform-specific workarounds.
If your team is evaluating cross platform mobile development options, the data below will help you decide whether KMP is ready for your project or whether React Native still makes more sense for your use case. You can also download our Complete Guide to Mobile App Development Planning and Costs for a broader view of what a mobile project involves.
Kotlin Multiplatform takes a fundamentally different approach to cross-platform development than React Native or Flutter. KMP compiles shared Kotlin code directly to native binaries for each target platform, without running a JavaScript runtime or a custom rendering engine on top of native platforms.
There is no runtime overhead, no interpretation layer, and no bridge between your shared code and the platform. The code runs as native on Android through the JVM and on iOS through Kotlin/Native, which produces native binaries. Kotlin's official documentation confirms that KMP compiles into the native execution model of each platform.
For teams coming from React Native, this is a meaningful architectural difference. React Native's new architecture in version 0.85 removed the bridge but still runs JavaScript on a virtual machine. KMP's native compilation means shared business logic performs identically to platform-native code.
To test KMP in a real scenario, I built Storium, a production-like e-commerce app. The app includes features that any real mobile product needs: authentication, offline caching, search and filtering, localization, encrypted storage, theming, and shared navigation.
The result was 7,851 lines of shared code out of 8,525 total lines. That is 92% code sharing, with platform-specific code split almost evenly between Android and iOS.
Typical KMP projects achieve 60 to 90% shared code according to real-world project data. Storium hit the high end because the app used Compose Multiplatform for UI, which allows sharing the presentation layer in addition to business logic.
I used Clean Architecture with MVI (Model-View-Intent) pattern in Storium. The shared library stack included:
Coming from a Kotlin-first background, the transition felt natural because the patterns, syntax, and tooling were already familiar to me.
The strongest advantage I found with KMP is how close the development experience feels to native Android. Kotlin developers can use the same language, same architecture patterns, and many of the same libraries they already know. The learning curve is minimal for teams already working in Kotlin.
Google officially endorsed KMP for business logic sharing in late 2023, which gave the technology credibility for enterprise adoption. Since then, KMP adoption has grown from 12% to 23% market share in 18 months, making it the fastest-growing cross-platform option according to industry analysis.
Companies including Duolingo, Forbes, Philips, McDonald's, and Booking.com use KMP in production. Booking.com published a detailed case study on using KMP for shared experimentation libraries across Android and iOS.
KMP's strengths are real, but I ran into friction points that React Native teams would not expect. The abstraction level is lower than React Native, which means some tasks that are trivial in other frameworks require manual platform-specific implementation.
Tasks like getting the current time, formatting dates, or accessing encrypted storage require expect/actual declarations. This is KMP's mechanism for platform-specific implementations: you declare an expect function in shared code and provide actual implementations for each platform.
In practice, this means writing and maintaining two implementations for common operations that React Native or Flutter handle with a single API call. The pattern is clean from an architecture perspective, but it added development time for routine tasks in my build.
On Kotlin Multiplatform iOS, Compose Multiplatform renders through the Skia graphics engine, not UIKit. This approach produces pixel-perfect visual consistency across platforms, but it introduces behavioral differences that iOS developers will notice.
Kotlinlang Slack discussions and developer reports document specific issues: shadow rendering differences, scroll bounce physics that do not match native iOS behavior, and text selection handling that feels slightly off. Skia shader compilation can also cause slow first renders on iOS, requiring workarounds like pre-warming shaders.
JetBrains stabilized Compose Multiplatform for iOS in May 2025 with version 1.8.0. Stable status means the API is reliable, but it does not mean the rendering behavior is indistinguishable from native iOS.
The iOS development loop with Compose Multiplatform is rebuild-based. There is no equivalent of React Native's Fast Refresh for iOS UI changes. Each change requires a full rebuild, which slowed down my iteration during UI development.
The core KMP stack (Ktor, Room, Koin, Navigation Compose, Coil) is production-ready. The problem I encountered is the long tail of third-party integrations that most production apps need.
Google does not ship an official Firebase SDK for Kotlin Multiplatform. The request has been open on Firebase's public feature board for years, and as of mid-2026, it still has not landed. I had to either wrap the native Firebase SDKs using expect/actual or use community libraries like GitLive's firebase-kotlin-sdk.
Push notifications require either community libraries like KMPNotifier or native integration through expect/actual wrappers. The community solutions work, but they add a dependency on a third-party maintainer for a feature that React Native handles through well-established official plugins.
The gap between core stack and ecosystem maturity follows a consistent pattern. For any third-party service your app needs, you will likely need to write custom native wrappers or rely on community-maintained libraries of varying quality. Booking.com's engineering team noted similar challenges when expanding beyond their initial KMP use cases.
Both frameworks have legitimate strengths. The choice depends on your team's expertise, project requirements, and integration needs.
| Dimension | KMP + Compose | React Native |
|---|---|---|
| Code sharing | Up to 92% (with Compose UI) | 70 to 90% (with shared logic) |
| Performance | Native compilation, no runtime | JS runtime (bridgeless in 0.85) |
| Language | Kotlin | JavaScript/TypeScript |
| iOS UI rendering | Skia (non-native) | Native components |
| Third-party SDKs | Growing, gaps in key areas | Mature, large plugin ecosystem |
| Team fit | Kotlin/Android teams | JS/web teams |
| Market share | 23% (growing fast) | 42% (established) |
KMP's growing adoption is significant. Industry data shows KMP surged from 12% to 23% in 18 months, the fastest growth rate among cross-platform frameworks. React Native still leads at 42% market share with 2.1 million developers, but the gap is narrowing.
For a deeper look at what changed in React Native recently, my colleagues published an investigation of React Native 0.85's bridge removal and what it means for cross-platform apps. You can also read our broader frameworks for cross-platform mobile development comparison.
KMP is a strong choice for specific project profiles. It is not a universal replacement for React Native or native development. Based on my investigation, here is a decision framework:
| Choose KMP if... | Wait or choose React Native if... |
|---|---|
| Your team is Kotlin-first | Your team is JavaScript/TypeScript-first |
| You need native-level performance | You need extensive third-party SDK integrations |
| Your app uses standard patterns (auth, CRUD, offline) | Your app requires pixel-perfect iOS native behavior |
| You can write expect/actual wrappers for gaps | You need Firebase Analytics, push, or other Google services without custom wrappers |
| Your UI can tolerate Skia rendering differences | You need Fast Refresh for rapid iOS UI iteration |
The foundation of KMP is excellent. The core libraries, the compilation model, and the architecture patterns are production-ready. The surrounding infrastructure (third-party SDKs, iOS developer experience, tooling) needs another generation or two to reach the maturity that React Native offers today.
For a full picture of what a mobile project involves beyond framework selection, download our Complete Guide to Mobile App Development Planning and Costs.
At NineTwoThree, we have been building cross-platform mobile apps for over a decade. Our team evaluates frameworks based on real project requirements, not trends. We have shipped 150+ projects and our mobile team includes engineers who work in Kotlin, Swift, React Native, and Flutter.
If you are deciding between KMP, React Native, or native development for your next mobile app, talk to our team. We will help you evaluate the tradeoffs based on your specific needs, team expertise, and project requirements.
You can also download our process for developing consumer mobile apps to see how we approach cross-platform builds from discovery to launch.
