Kotlin Multiplatform for Mobile Cheat Sheet

Updated 2026-05-16

Next Topic: Mobile Accessibility Implementation Cheat Sheet

🧠Study flashcards on this topic111 cards · spaced repetition→

Kotlin Multiplatform for Mobile (KMP, also known as KMM) is JetBrains' official technology for sharing Kotlin code between Android and iOS applications while maintaining native UI on each platform. Unlike cross-platform frameworks that force a single UI paradigm, KMP focuses on sharing business logic, networking, data persistence, and domain layers while letting developers use native toolkits (Jetpack Compose on Android, SwiftUI/UIKit on iOS) for platform-specific experiences. As of 2026, KMP is production-ready and stable, with Compose Multiplatform enabling optional UI sharing across platforms. KMP eliminates code duplication without sacrificing native performance, and its incremental adoption path allows teams to migrate existing native apps module-by-module rather than rewriting from scratch.

What This Cheat Sheet Covers

This topic spans 20 focused tables and 204 indexed concepts, 111 flashcards. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Core KMP Architecture ConceptsTable 2: expect/actual DeclarationsTable 3: Platform-Specific ImplementationsTable 4: Shared Code Architecture PatternsTable 5: Networking with Ktor ClientTable 6: Data PersistenceTable 7: Serialization with kotlinx.serializationTable 8: Coroutines and Flow in Shared CodeTable 9: Source Sets and Module StructureTable 10: Gradle ConfigurationTable 11: iOS Integration and Swift InteropTable 12: Testing Shared ModulesTable 13: Dependency Injection with KoinTable 14: Compose Multiplatform for Shared UITable 15: Migration from Native AppsTable 16: Compose Multiplatform ResourcesTable 17: CI/CD and PublishingTable 18: Performance and OptimizationTable 19: Advanced KMP TechniquesTable 20: IDE and Tooling

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Core KMP Architecture Concepts

Everything in KMP starts with source sets — folders that decide which platforms a given chunk of Kotlin compiles to. The vocabulary here is the foundation for the rest of the sheet: commonMain holds the shared business logic, androidMain and iosMain plug in the platform-specific pieces, and expect/actual bridges the two. Grasp how these layers stack — plus the hybrid "shared logic, native UI" pattern most teams settle on — and the rest of KMP stops feeling like magic.

Concept	Example	Description
commonMain source set	`src/commonMain/kotlin/` `// Shared business logic`	• The shared codebase where platform-agnostic Kotlin code lives • Accessible to all targets • Contains networking, domain logic, repositories, ViewModels, and utilities • Compiles to all declared platforms
androidMain source set	`src/androidMain/kotlin/` `// Android-specific code`	• Android-specific implementation layer • Accesses Android SDK APIs directly • Provides `actual` implementations for Android platform • Compiled with Kotlin/JVM for Android targets
iosMain source set	`src/iosMain/kotlin/` `// iOS-specific code`	• iOS-specific implementation layer • Accesses iOS frameworks like UIKit and CoreData • Provides `actual` implementations for iOS platform • Compiled with Kotlin/Native to native iOS binaries
Shared module	`shared/` (or `composeApp/`)	• The KMP library module containing common, Android, and iOS source sets • Generated as an `.aar` for Android and `.framework`/Swift Package for iOS • Defines shared targets in `build.gradle.kts`
Source set hierarchy	`commonMain` → `iosMain` → `iosArm64Main`	• Dependency chain of source sets • Child sets inherit code from parent sets • Enables incremental platform specificity • Default hierarchy template simplifies target configuration
expect/actual mechanism	`expect fun platform(): String` `actual fun platform() = "Android"`	• Platform-specific API access from common code • `expect` declares API in `commonMain` • `actual` provides platform implementation in `androidMain`/`iosMain` • Compiler ensures all targets provide implementations
Kotlin/Native interop	`import platform.UIKit.*` `val view = UIView()`	• Direct access to iOS frameworks from Kotlin • Automatically generates Kotlin bindings for Objective-C/Swift APIs • Bidirectional interoperability • Uses cinterop definitions for C libraries
Swift export	Kotlin → Swift idiomatic APIs	• Kotlin-to-Swift direct export without Objective-C headers (enabled by default in Kotlin 2.1+) • Eliminates manual bridging • Exposes Kotlin classes, functions, and types idiomatically in Swift • Supports generics and suspend functions
Gradle plugin setup	`kotlin("multiplatform") version "2.1.0"` `targets { android(); iosArm64() }`	• Configures multiplatform compilation in `build.gradle.kts` • Declares target platforms • Sets up source sets automatically • Manages platform-specific dependencies
Shared logic + native UI	Business logic in `commonMain` UI: Jetpack Compose + SwiftUI	• Hybrid architecture that shares code without forcing UI uniformity • Networking, database, domain models, and repositories are shared • UI remains 100% native for platform fidelity • Most common KMP pattern in 2026
Compose Multiplatform	Shared UI across Android, iOS, desktop, web	• Optional cross-platform declarative UI framework built on Jetpack Compose • Enables sharing up to 100% of code including UI • Production-ready for mobile and desktop as of 2026 • Uses native rendering on each platform

Table 2: expect/actual Declarations

When shared code needs something only a platform can provide — a logger, a database driver, a UUID — you declare an expect in commonMain and supply a matching actual in each platform set. The patterns below cover the full range: functions, classes, objects, properties, typealiases, even inline functions. Note the recurring advice at the bottom: expect/actual creates tight compiler coupling, so for anything you'll want to mock in tests, plain interfaces plus DI often age better.

Pattern	Example	Description
expect function	`expect fun logMessage(msg: String)`	• Declares a function signature in `commonMain` without implementation • Requires `actual` implementation in each platform source set • Used for platform-specific operations

The rest of this section is part of the full cheat sheet

Table 3: Platform-Specific Implementations

Beyond expect/actual, there are several ways to reach native APIs and libraries from KMP — and picking the right one matters for testability and build sanity. These techniques span calling iOS frameworks directly from iosMain, wiring up Android- or iOS-only dependencies, the ongoing move from CocoaPods to Swift Package Manager, and the increasingly popular alternative of injecting platform implementations through Koin rather than hard-coding them.

Technique	Example	Description
Direct iOS framework access	`import platform.UIKit.UIDevice` `UIDevice.currentDevice.systemVersion`	• Call iOS frameworks directly from `iosMain` • No bridging code required • Kotlin/Native generates interop automatically • Access UIKit, Foundation, CoreData, etc.

The rest of this section is part of the full cheat sheet

Table 4: Shared Code Architecture Patterns

How much you share — and how you structure it — is the big architectural decision in any KMP project. The patterns here run from lightweight (just shared repositories and use cases consumed by native UI) to fully shared MVI state and Clean Architecture layers. A useful way to read this table is as a spectrum: start with shared services, reach for MVI or modular feature splits only when the app's complexity actually demands it.

Pattern	Example	Description
Shared Services architecture	Repositories + UseCases in `commonMain`	• Business logic and data access shared • Minimal boilerplate • Native UI on each platform consumes shared services • Most common KMP pattern

The rest of this section is part of the full cheat sheet

Table 1: Core KMP Architecture Concepts

Concept	Example	Description
commonMain source set	`src/commonMain/kotlin/` `// Shared business logic`	• The shared codebase where platform-agnostic Kotlin code lives • Accessible to all targets • Contains networking, domain logic, repositories, ViewModels, and utilities • Compiles to all declared platforms
androidMain source set	`src/androidMain/kotlin/` `// Android-specific code`	• Android-specific implementation layer • Accesses Android SDK APIs directly • Provides `actual` implementations for Android platform • Compiled with Kotlin/JVM for Android targets
iosMain source set	`src/iosMain/kotlin/` `// iOS-specific code`	• iOS-specific implementation layer • Accesses iOS frameworks like UIKit and CoreData • Provides `actual` implementations for iOS platform • Compiled with Kotlin/Native to native iOS binaries
Shared module	`shared/` (or `composeApp/`)	• The KMP library module containing common, Android, and iOS source sets • Generated as an `.aar` for Android and `.framework`/Swift Package for iOS • Defines shared targets in `build.gradle.kts`
Source set hierarchy	`commonMain` → `iosMain` → `iosArm64Main`	• Dependency chain of source sets • Child sets inherit code from parent sets • Enables incremental platform specificity • Default hierarchy template simplifies target configuration
expect/actual mechanism	`expect fun platform(): String` `actual fun platform() = "Android"`	• Platform-specific API access from common code • `expect` declares API in `commonMain` • `actual` provides platform implementation in `androidMain`/`iosMain` • Compiler ensures all targets provide implementations
Kotlin/Native interop	`import platform.UIKit.*` `val view = UIView()`	• Direct access to iOS frameworks from Kotlin • Automatically generates Kotlin bindings for Objective-C/Swift APIs • Bidirectional interoperability • Uses cinterop definitions for C libraries
Swift export	Kotlin → Swift idiomatic APIs	• Kotlin-to-Swift direct export without Objective-C headers (enabled by default in Kotlin 2.1+) • Eliminates manual bridging • Exposes Kotlin classes, functions, and types idiomatically in Swift • Supports generics and suspend functions
Gradle plugin setup	`kotlin("multiplatform") version "2.1.0"` `targets { android(); iosArm64() }`	• Configures multiplatform compilation in `build.gradle.kts` • Declares target platforms • Sets up source sets automatically • Manages platform-specific dependencies
Shared logic + native UI	Business logic in `commonMain` UI: Jetpack Compose + SwiftUI	• Hybrid architecture that shares code without forcing UI uniformity • Networking, database, domain models, and repositories are shared • UI remains 100% native for platform fidelity • Most common KMP pattern in 2026
Compose Multiplatform	Shared UI across Android, iOS, desktop, web	• Optional cross-platform declarative UI framework built on Jetpack Compose • Enables sharing up to 100% of code including UI • Production-ready for mobile and desktop as of 2026 • Uses native rendering on each platform

Table 2: expect/actual Declarations

Pattern	Example	Description
expect function	`expect fun logMessage(msg: String)`	• Declares a function signature in `commonMain` without implementation • Requires `actual` implementation in each platform source set • Used for platform-specific operations

Table 3: Platform-Specific Implementations

Technique	Example	Description
Direct iOS framework access	`import platform.UIKit.UIDevice` `UIDevice.currentDevice.systemVersion`	• Call iOS frameworks directly from `iosMain` • No bridging code required • Kotlin/Native generates interop automatically • Access UIKit, Foundation, CoreData, etc.

Table 4: Shared Code Architecture Patterns

Pattern	Example	Description
Shared Services architecture	Repositories + UseCases in `commonMain`	• Business logic and data access shared • Minimal boilerplate • Native UI on each platform consumes shared services • Most common KMP pattern