The short answer
Kotlin Multiplatform (KMP) makes sense when you already have, or plan, an Android app in Kotlin with a lot of business logic worth writing once: sync rules, pricing, validation, offline storage. Native Swift is simpler when the app is iOS-first, the logic is light and most of the work is in the interface.
What Kotlin Multiplatform is
KMP is JetBrains’ technology for sharing Kotlin code across Android, iOS, desktop and web. JetBrains lists the core technology as Stable on iOS (supported platforms). There are two ways to use it on iPhone:
- Share the logic, keep the interface native. Networking, data and business rules live in a shared Kotlin module; the iOS interface is written in SwiftUI and calls into it.
- Share the interface too, with Compose Multiplatform. JetBrains also lists Compose Multiplatform as Stable on iOS (Compose Multiplatform). Like Flutter, it draws its own interface rather than using Apple’s controls, and it can be mixed with existing SwiftUI screens.
Side by side
| Native Swift | KMP, shared logic | KMP with Compose UI | |
|---|---|---|---|
| Interface | SwiftUI and UIKit | SwiftUI and UIKit | Drawn by Compose |
| Shared with Android | Nothing | Business logic | Logic and interface |
| Languages on iOS | Swift | Swift and Kotlin | Mostly Kotlin |
| New iOS features | Day one | Day one, in the Swift layer | When the framework supports them |
| Build tooling | Xcode | Xcode and Gradle | Xcode and Gradle |
| Best for | iOS-first products | Heavy shared rules, native feel | One team, one look on both |
The trade-offs people underestimate
- Two toolchains. iOS builds involve Gradle as well as Xcode, and someone on the team has to be comfortable with both.
- Who owns the shared module. If Android engineers own it, iOS changes wait on their schedule. Agree this before you start.
- Crossing the boundary. Kotlin code reaches Swift through generated bindings, and APIs that feel natural in Kotlin can feel awkward in Swift. Designing the shared API for both sides takes care.
- Debugging across languages. JetBrains’ tools support stepping between Kotlin and Swift, but it is still two languages to reason about.
- What is worth sharing. Interface code is where most iOS-specific work lives. Sharing logic saves less time on an app whose logic is light.
When KMP is the better choice
- You have a Kotlin Android app with substantial business logic, and iOS has to behave identically.
- Rules such as pricing, validation or sync are complex enough that two versions would drift apart.
- Your team is Kotlin-first and can staff the iOS layer as well.
When native Swift is the better choice
- The product is iPhone-first, or iOS is the only platform for now.
- Most of the work is the interface: flows, animation, gestures, design.
- The app leans on Apple frameworks such as StoreKit, CloudKit, WidgetKit, App Intents or Foundation Models.
- You want one language and one toolchain on iOS.
For the broader picture, see Swift vs Flutter and why we only build in Swift.
Related: Swift vs Flutter · Why we only build in Swift · SwiftUI vs UIKit