Kotlin Multiplatform: Share Code Across Platforms

Kotlin Multiplatform

Kotlin Multiplatform (KMP) lets teams write code once in Kotlin and use it on Android, iOS, desktop, web, and servers — while still building native apps on each platform. Unlike frameworks that replace the whole app stack, KMP starts with sharing what is identical everywhere: business rules, data models, networking, caching, and validation. Each platform keeps its native UI and platform APIs, calling the shared module like any other library. For teams that also want shared UI, Compose Multiplatform extends Jetpack Compose to iOS, desktop, and the web.

KMP has been stable since late 2023, and Google supports it for sharing business logic between Android and iOS. Its appeal is incremental adoption: a team can share one module — say, the API client — without rewriting either app.

TL;DR

Code lives in source sets: commonMain for shared code, plus androidMain, iosMain, jvmMain, and others for platform code.
expect/actual declarations define a common API with platform-specific implementations.
Kotlin/Native compiles shared code into an iOS framework that Swift imports.
Multiplatform libraries cover essentials: Ktor Client, kotlinx.coroutines, kotlinx.serialization, SQLDelight or Room, Koin.
Compose Multiplatform optionally shares UI; many teams share logic and keep native UI.
Adopt incrementally: start with one shared module and grow it.

Quick Example

A shared module's Gradle configuration:

Shared code with a platform-specific piece:

Swift uses the shared framework directly:

Core Concepts

Targets and Source Sets

A KMP module declares targets — androidTarget(), iosArm64(), jvm(), js(), wasmJs() — and organizes code in source sets. commonMain code can use only Kotlin's common standard library and multiplatform dependencies; platform source sets can call platform APIs (Android SDK, UIKit and Foundation through Kotlin/Native interop, JVM libraries). Intermediate source sets such as iosMain share code among related targets automatically.

expect and actual

expect declarations in common code promise a function, class, or property; each platform supplies an actual implementation. Use them sparingly for small platform capabilities — UUIDs, dates, secure storage, logging — and prefer interfaces with platform implementations injected at startup for anything larger, which keeps code testable.

Kotlin/Native and iOS

For Apple platforms, Kotlin/Native compiles shared code to native binaries packaged as a framework (often an XCFramework) consumed through Swift Package Manager, CocoaPods, or direct Xcode integration. Swift sees an Objective-C-style API: Kotlin classes, functions, and data types map well, while some features — generics variance, sealed classes, suspend functions, and Flow — are less natural. Tools such as SKIE improve the generated Swift API, and Swift export is evolving to provide a native Swift interface.

Multiplatform Libraries

See Ktor.

Compose Multiplatform

Compose Multiplatform shares declarative UI code across Android, iOS, desktop, and web, rendering with its own engine on non-Android platforms. Teams can share entire screens, share only some components, or keep fully native UI and share logic — the choice can differ per feature.

KMP Compared With Other Cross-Platform Approaches

See Flutter vs React Native.

Testing

Tests in commonTest run on every target using kotlin.test, so shared logic is verified on the JVM and on iOS simulators. Coroutine code uses kotlinx-coroutines-test. Platform-specific code is tested in platform test source sets, and app-level UI tests remain native.

Best Practices

Start With the Data and Networking Layer

API clients, models, validation, and caching are identical across platforms and give the biggest early payoff.

Design the Swift-Facing API Deliberately

Expose simple, Swift-friendly types and callbacks or wrapped flows, and involve iOS developers in API design so the shared module feels natural in Swift.

Keep Platform Code Behind Interfaces

Inject platform capabilities rather than scattering expect/actual through business logic.

Mind iOS Build Times and Binary Size

Kotlin/Native builds are slower than JVM builds and frameworks add size. Cache builds in CI, build only needed architectures in development, and monitor framework size.

Common Mistakes

Sharing Everything on Day One

Leaking Kotlin Idioms Into Swift

Using JVM-Only Libraries in commonMain

FAQ

What is Kotlin Multiplatform?

A Kotlin technology for sharing code across platforms — Android, iOS, desktop, web, and server — compiling shared Kotlin to each platform's native format while allowing platform-specific code where needed.

Does Kotlin Multiplatform share UI?

Not by default; it focuses on sharing logic. Compose Multiplatform adds shared UI across Android, iOS, desktop, and web for teams that want it.

How does iOS use Kotlin code?

Kotlin/Native compiles the shared module into an Apple framework. Swift imports it like any framework, with Kotlin types exposed through an Objective-C-compatible interface that tools can make more Swift-idiomatic.

Is Kotlin Multiplatform production-ready?

Yes. It has been stable since 2023, and many companies ship KMP code in production apps. Google supports it for sharing business logic between Android and iOS.

KMP or Flutter?

KMP suits teams that want native UI and gradual adoption alongside existing apps, especially with Kotlin expertise. Flutter suits teams wanting a single UI toolkit and codebase for all platforms from the start.