How it works
Shared code lives in a common module and compiles to each platform's native form: JVM bytecode on Android, a native framework on iOS (through Kotlin/Native), JavaScript or WebAssembly on the web. Where a platform needs its own implementation, expect and actual declarations mark the gap. Ktor, kotlinx.serialization, coroutines, Room, DataStore, SQLDelight and supabase-kt all work in shared code.
Teams choose how much to share. Many keep native interfaces (Jetpack Compose on Android, SwiftUI on iOS) and share networking, storage and business rules; others share the interface too with Compose Multiplatform, whose iOS support became stable in 2025. Google officially supports KMP for sharing logic, and it can be added to an existing Android app one module at a time.
Kotlin Multiplatform pros and cons
Pros
- Share as much or as little as you like, even one module in an existing app
- Native performance, and native UI where you want it
- Android teams reuse their Kotlin skills and many Jetpack libraries
- Backed by JetBrains and officially supported by Google
Cons
- iOS developers must work with Kotlin code and its build tooling
- Smaller library ecosystem than Flutter or React Native
- iOS builds still need a Mac, and Kotlin/Native builds can be slow
When to use Kotlin Multiplatform
Pick it when
- An existing Android app that is adding iOS
- Apps with complex shared logic such as sync, offline data or business rules
- Teams that want native interfaces but one copy of the logic
Skip it when
- A web-focused team, where React Native or Capacitor fits better
- A team with no Kotlin experience that wants a quick route to both stores
Kotlin Multiplatform pricing
Kotlin Multiplatform vs the alternatives
Related terms
More in Mobile apps
Cross-platform