Choose Kotlin Multiplatform (KMP) when your team is strong in Kotlin, when you already have native Android and iOS apps and want to stop writing the same logic twice, or when you want native UI on each platform with one shared core. Add Compose Multiplatform if you also want to share the UI; it has been stable on iOS since release 1.8.0 in May 2025. Look elsewhere when you have no iOS developers willing to work with Kotlin, or when a React or web team would be more productive in React Native or Flutter.
KMP is the option with the most "it depends" in it, because it lets you choose how much to share. This post explains what it shares, where Compose Multiplatform stands on iOS today, and how we would introduce it.
What Kotlin Multiplatform shares, and what it does not
KMP compiles Kotlin code for several targets: for Android it is ordinary Kotlin on the JVM; for iOS it compiles to native code that Swift can call. The core technology is stable on Android, iOS and desktop JVM, and Google states that it officially supports KMP for sharing business logic between Android and iOS.
A KMP project puts shared code in a common source set and platform-specific code alongside it.
shared/src/commonMain/kotlin # logic for every platform shared/src/androidMain/kotlin # Android-specific implementations shared/src/iosMain/kotlin # iOS-specific implementations
What typically goes into the shared module:
- Data models, validation and business rules.
- Networking and API clients.
- Local storage and offline sync logic. Several Jetpack libraries now support KMP, including Room, DataStore, ViewModel, Lifecycle and Navigation.
- Calculations that must match on both platforms: pricing, tax, scheduling rules.
The UI is the choice you make on top. Either each platform keeps its own native UI (SwiftUI on iOS, Jetpack Compose on Android), or you share the UI too with Compose Multiplatform.
Compose Multiplatform on iOS today
Compose Multiplatform is JetBrains' port of Jetpack Compose to other platforms. Its status as it stands now:
| Platform | Compose Multiplatform status |
|---|---|
| Android | Stable (it is Jetpack Compose) |
| iOS | Stable since 1.8.0 (May 2025) |
| Desktop (JVM) | Stable |
| Web (Kotlin/Wasm) | Beta |
Stable does not mean identical to native. On iOS, Compose Multiplatform draws its own UI rather than using UIKit controls, much as Flutter does, so native feel depends on how well its components mimic iOS. JetBrains keeps closing the gaps: release 1.11 (May 2026) added an experimental native text input built on UIKit's UIView, for native caret movement, gestures and system menus. Treat text-heavy screens and platform-specific interactions as the places to test first.
A second detail matters to your iOS developers. Kotlin code is exposed to Swift through Objective-C headers today. The newer Swift export, which exposes Kotlin to Swift directly and more idiomatically, is still Alpha, with breaking changes expected. It is fine to prototype with; we would not build a production release process on it yet.
Where Kotlin Multiplatform is the right choice
You have native apps already. KMP is the only option here that does not ask you to rewrite. You can move one piece of logic into a shared module, ship it inside both existing apps, and keep going.
Your team is Android and Kotlin first. Kotlin developers stay in their language and tools. With Compose Multiplatform, Android developers can build iOS screens with the skills they have.
Complex rules that must run on the device. Offline field apps that price, validate or schedule locally need identical results on both platforms. Sharing that code removes a whole class of "the iPhone calculates it differently" bugs.
You want native UI but not double logic. For apps where the iOS experience must feel fully native, shared logic with SwiftUI on top keeps the look native and the rules single.
Where it is not the best fit
No iOS buy-in. If there is no one on the iOS side willing to work with a Kotlin module, the project will struggle regardless of the technology.
A JavaScript or web-first team. React developers will be productive faster in React Native.
One small team, starting fresh, sharing everything. Compose Multiplatform can do it, but Flutter has a longer track record for full UI sharing on iOS and a larger package ecosystem. We would compare the two on your team's skills and your plugin list.
Adopting KMP one module at a time
- Pick one self-contained piece of logic. An API client, a validation library or a pricing engine. Not the UI.
- Agree the Swift-facing API with the iOS team. Design how iOS will call it before writing it, and review the generated interface together.
- Ship it in both apps. Wire the module into the Android and iOS builds and your CI, and release it.
- Move storage and sync next. With KMP-ready libraries such as Room and DataStore, offline data handling is a natural second step. See offline-first mobile apps and sync architecture.
- Decide about shared UI last. Try Compose Multiplatform on one new screen on iOS, test it on real devices, and only then decide whether to go further.
If KMP sounds right, compare it with fully native apps and read the overview in choosing a mobile app framework. Our mobile app development team can help plan where the shared code should start and stop.
Questions we get asked
Is Compose Multiplatform stable on iOS?
Yes. JetBrains declared Compose Multiplatform for iOS stable and production-ready with release 1.8.0 in May 2025, and later releases continue to improve it. It draws its own UI on iOS rather than using native controls, so test text input and platform-specific interactions carefully. Web support, based on Kotlin/Wasm, is still in Beta.
What is the difference between Kotlin Multiplatform and Compose Multiplatform?
Kotlin Multiplatform is the technology for sharing Kotlin code, such as business logic, networking and storage, across Android, iOS, desktop and web. Compose Multiplatform is JetBrains' UI framework built on top of it, which lets you share the user interface as well. You can use Kotlin Multiplatform with fully native UIs and never adopt Compose Multiplatform.
Kotlin Multiplatform or Flutter?
Choose Kotlin Multiplatform if your team knows Kotlin, you have existing native apps, or you want native UI with shared logic. Choose Flutter if one team is starting fresh and wants to share the whole UI with a large package ecosystem. Both can share the full interface; the deciding factors are usually your team's skills and your existing code.
Can I add Kotlin Multiplatform to an existing app?
Yes, and that is one of its main strengths. You can move a single piece of logic, such as an API client or a validation module, into a shared Kotlin module and use it from both an existing Android app and an existing iOS app. Nothing else needs to change, and you can expand the shared code gradually.
Does Google support Kotlin Multiplatform?
Yes. Google's Android documentation states that Kotlin Multiplatform is officially supported for sharing business logic between Android and iOS, and describes it as stable and production-ready. Several Jetpack libraries, including Room, DataStore, ViewModel, Lifecycle and Navigation, support Kotlin Multiplatform, so Android developers can reuse familiar libraries in shared code.