Cross-Platform Mobile App Development with Kotlin Multiplatform
Kotlin Multiplatform reached Stable status in November 2023 — with KMP 1.9.20. This is not «write once — run everywhere» in Flutter's sense. KMP allows sharing business logic between iOS and Android while keeping native UI on each platform. Architecturally: common module in Kotlin compiles to JVM bytecode for Android and native framework via Kotlin/Native for iOS (xcframework through Gradle task assembleXCFramework).
Main consequence: no UI compromises — SwiftUI on iOS, Jetpack Compose on Android. No «same look on both platforms» — each platform looks native. Shared layer — only commonMain: network layer, business logic, domain models, local DB.
What goes to shared, what stays native
In commonMain: network requests via Ktor Client (io.ktor:ktor-client-core), serialization via kotlinx.serialization, local DB via SQLDelight (generates typed Kotlin API from SQL files), domain models, use cases, ViewModels via kotlinx.coroutines + StateFlow.
Stays native: UI entirely (SwiftUI / UIKit on iOS, Compose / XML on Android), camera access, biometrics, push notifications (APNs vs FCM), native payment SDKs. Native API access — via expect/actual mechanism: declare expect class PlatformSpecific in commonMain, write actual implementations in androidMain and iosMain.
Typical Kotlin/Native pain — multithreading. Before KMP 1.7.20 any object created in one thread couldn't be accessed from another — InvalidMutabilityException. With new MM (Memory Manager) in 1.7.20 this limitation is lifted, but legacy code may contain freeze() patterns now outdated. When auditing old KMP projects this is the first thing we check.
iOS integration
xcframework connected in Xcode via SPM (Swift Package Manager) or Cocoapods with pod 'shared'. SPM integration preferable with XCode 15+: binaryTarget in Package.swift with local path to xcframework. Framework update — ./gradlew assembleXCFramework in Gradle, then build in Xcode.
Calling suspend functions from Swift requires wrappers: Swift doesn't natively call Kotlin coroutines. Solution — KMMBridge from Touchlab or manual wrappers via Kotlinx.coroutines + CoroutineScope on Kotlin side, exporting callback-based API. With Kotlin 1.9.20 there's experimental @Throws + Swift async/await via kotlin.native.concurrent, but in production requires testing.
Case study. FinTech app: iOS (SwiftUI + Combine) and Android (Compose + Flow) share common business logic — credit limit calculation, form validation, caching via SQLDelight. Ktor Client configured with OkHttp engine on Android and Darwin (NSURLSession) engine on iOS. Common AuthInterceptor in commonMain adds JWT token to every request. Shared module tests — kotlin.test + runTest for coroutines. CI — GitHub Actions: ./gradlew :shared:allTests runs tests on JVM and via K/N test runner on iOS simulator.
SQLDelight vs Room vs Realm
| DB | Shared support | API type | Suitable for |
|---|---|---|---|
| SQLDelight | Yes (commonMain) | Typed Kotlin from SQL | KMP projects |
| Room | Android only | DAO + Kotlin | Android only |
| Realm Kotlin | Yes (commonMain) | Object-oriented | Reactive apps |
SQLDelight — our default choice for KMP: SQL schema is one, API generated for both platforms.
Timelines
| Scope | Approximate timeline |
|---|---|
| Shared business logic + native UI, MVP | 10–16 weeks |
| Full product with offline | 5–9 months |
| Existing Android app migration | 3–6 months |
Cost calculated individually. KMP requires team with competencies in both native platforms — this is key factor when estimating budget.