KMP in 2026: Architecture, Establishment and Ecosystem of Kotlin Multiplatform
For years, Kotlin Multiplatform (KMP) has been labeled "interesting but not yet ready for production". In 2026, this narrative has definitively changed: KMP has reached maturity enterprise with stable iOS API, Compose Multiplatform stable on all major platforms, e Swift Export which finally eliminates the need for Objective-C bridging for interoperability with native Swift code.
This guide provides a comprehensive overview of the KMP ecosystem in 2026: what has changed since to previous years, how it compares to Flutter and React Native, what is the correct architecture for a cross-platform project, and how to evaluate whether KMP is the right choice for your use case.
What You Will Learn
- KMP architecture: shared modules, source set and platform-specific code
- KMP vs Flutter vs React Native: technical comparison updated to 2026
- Swift Export and native interop with iOS
- Compose Multiplatform: Current status and limitations
- KMP 2026 library ecosystem: Ktor, SQLDelight, Koin
- When to choose KMP and when not
The Quality Leap in 2025-2026
KMP 1.0 was already stable for sharing business logic, but suffered from important limitations: iOS integration required automatically generated Objective-C headers (not very idiomatic for Swift developers), and Compose Multiplatform still had many APIs in alpha on iOS and desktop.
The main changes that occurred between 2024 and 2026:
- Swift Export (stable in KMP 1.9+): Generate native Swift API with naming idiomatic, protocols, default arguments, and no intermediate Objective-C. The developers iOS now consumes Kotlin code as if it were pure Swift.
- Compose Multiplatform 1.7+ (stable on iOS): Fully shared UI in Kotlin/Compose on Android, iOS, Desktop (JVM) and Web (Wasm). Platform-specific rendering engines they are now mature and the performance is acceptable even for complex apps.
- Amper build system (beta): simplified alternative to Gradle for KMP projects, with YAML setup instead of complex Kotlin DSL.
- Improved Tooling: Android Studio Ladybug and later have KMP support world-class with cross-platform refactoring, debugging on the built-in iOS simulator, and profiling.
Architecture of a KMP Project
The fundamental architecture of KMP is based on the separation of shared code (commonMain) and platform-specific code. It's not about "writing everything once" as React Native promised, but to share the logic that makes sense to share and delegate to the platform what is intrinsically native.
// Struttura tipica di un progetto KMP nel 2026
shared/
├── src/
│ ├── commonMain/kotlin/
│ │ ├── data/
│ │ │ ├── repository/ # Repository patterns condivisi
│ │ │ ├── network/ # Ktor client (HTTP multiplatform)
│ │ │ └── local/ # SQLDelight (DB multiplatform)
│ │ ├── domain/
│ │ │ ├── model/ # Data classes pure Kotlin
│ │ │ ├── usecase/ # Logica business
│ │ │ └── repository/ # Interfacce repository
│ │ └── presentation/ # ViewModels (Compose o altri)
│ │
│ ├── androidMain/kotlin/
│ │ └── actual/ # Implementazioni Android-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ ├── iosMain/kotlin/
│ │ └── actual/ # Implementazioni iOS-specific
│ │ ├── DatabaseDriver.kt
│ │ └── HttpEngine.kt
│ │
│ └── desktopMain/kotlin/ # (opzionale, per desktop JVM)
│
androidApp/ # App Android con UI nativa
iosApp/ # App iOS con UI nativa (Swift/SwiftUI)
desktopApp/ # App desktop (opzionale)
composeApp/ # (alternativa: UI condivisa con Compose MP)
The guiding principle: share as much as possible, use native APIs when necessary. Typically, a mature KMP application shares:
- 90-95% of business logic (domain layer)
- 80-85% of the data layer (network, persistence, caching)
- 40-80% of the presentation layer (depends on whether Compose Multiplatform is used)
- 0-20% of UI layer (if using platform-specific native UI)
KMP vs Flutter vs React Native: The 2026 Comparison
The question "which cross-platform framework to use?" has different answers in 2026 than in 2022. Here's an honest comparison:
// Matrice decisionale semplificata
| KMP | Flutter | React Native
--------------------|--------------|-------------|-------------
Linguaggio | Kotlin | Dart | TypeScript/JS
UI Engine | Nativa o CMP | Custom (Skia)| Nativa (bridge)
Performance | Ottima | Buona | Buona
Look nativo | Perfetto | Non nativo | Parziale
Team Android-first | Eccellente | Buono | Buono
Condivisione codice | ~70-80% | ~95% | ~80-90%
Ecosistema librerie | Crescente | Maturo | Maturo
Enterprise adoption | Alta (2026) | Alta | Diminuzione
The key difference: Flutter uses a custom rendering engine (Impeller) to draw the entire UI, ensuring cross-platform visual consistency but at the expense of the "native" look of the platform. KMP with native UI looks exactly like a native app because USA the components native to the platform.
When to Choose KMP
KMP is the optimal choice when:
- The team has strong Android/Kotlin expertise and wants to bring that logic to iOS
- The "native" aspect of the UI is a non-negotiable requirement (banking apps, enterprise)
- You want to share business logic while maintaining total control over the platform-specific UI
- Application has complex business logic (preferable to isolate from UI issues)
- You're adding iOS to an existing Android app without rewriting everything
Flutter or React Native might be preferable when:
- The team has web/React skills and wants to reuse them
- You want to maximize UI sharing (not just logic)
- Time to market is critical and the team doesn't know Kotlin
Swift Export: iOS Interoperability in 2026
Before Swift Export, shared Kotlin code was exposed to iOS through headers Automatically generated Objective-C. The result was API like this:
// PRIMA (Objective-C headers generati da KMP):
// Swift deve usare classi con nomi generati automaticamente
let viewModel = SharedUserViewModel()
let users = viewModel.users as! [SharedUser]
viewModel.loadUsers(completionHandler: { users, error in
// Gestione callback non-idiomatica
})
// DOPO (Swift Export in KMP 1.9+):
// Swift idiomatico, direttamente da codice Kotlin
let viewModel = UserViewModel()
let users: [User] = viewModel.users
await viewModel.loadUsers() // async/await nativo Swift
Swift Export automatically translates Kotlin coroutines to async/await Swift,
data classes in Swift struct (with automatic equatable), sealed classes in Swift enums,
and Flows in AsyncSequence. The result is that iOS developers consume the Kotlin API
as if it were written in Swift.
Compose Multiplatform: Current Status
Compose Multiplatform (CMP) allows you to share the entire UI written in Compose Kotlin on Android, iOS, Desktop JVM and Web (via Kotlin/Wasm). In 2026, the established on iOS and significantly improved compared to the initial betas:
// commonMain: UI condivisa con Compose Multiplatform
@Composable
fun UserListScreen(
users: List<User>,
onUserClick: (User) -> Unit
) {
LazyColumn {
items(users) { user ->
UserCard(user = user, onClick = { onUserClick(user) })
}
}
}
@Composable
fun UserCard(user: User, onClick: () -> Unit) {
Card(
modifier = Modifier
.fillMaxWidth()
.padding(horizontal = 16.dp, vertical = 8.dp)
.clickable(onClick = onClick)
) {
Column(modifier = Modifier.padding(16.dp)) {
Text(user.name, style = MaterialTheme.typography.titleMedium)
Text(user.email, style = MaterialTheme.typography.bodySmall)
}
}
}
The Compose UI is identical on Android and iOS. Rendering uses Skiko (Skia's Kotlin binding) on iOS instead of native UIKit components, which means the app has a consistent look cross-platform but not identical to a native SwiftUI app.
The KMP Library Ecosystem in 2026
An ecosystem of mature libraries is essential for productivity. In 2026, these are the fundamental libraries for a KMP project:
// build.gradle.kts (shared module)
kotlin {
sourceSets {
commonMain.dependencies {
// Network: client HTTP multiplatform
implementation("io.ktor:ktor-client-core:2.3.10")
implementation("io.ktor:ktor-client-content-negotiation:2.3.10")
implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.10")
// Database: SQL multiplatform
implementation("app.cash.sqldelight:runtime:2.0.2")
// Serialization
implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.0")
// Coroutines multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.8.1")
// Dependency Injection
implementation("io.insert-koin:koin-core:3.5.6")
// DateTime multiplatform
implementation("org.jetbrains.kotlinx:kotlinx-datetime:0.6.0")
// Logging multiplatform
implementation("co.touchlab:kermit:2.0.3")
}
androidMain.dependencies {
implementation("io.ktor:ktor-client-okhttp:2.3.10")
implementation("app.cash.sqldelight:android-driver:2.0.2")
}
iosMain.dependencies {
implementation("io.ktor:ktor-client-darwin:2.3.10")
implementation("app.cash.sqldelight:native-driver:2.0.2")
}
}
}
A Complete Example: Pattern Repository in KMP
Let's see how to implement a simple repository for user management in KMP, showing the separation between common and platform-specific code:
// commonMain: Interfaccia repository e modello
data class User(
val id: Long,
val name: String,
val email: String,
val createdAt: Instant
)
interface UserRepository {
suspend fun getUsers(): List<User>
suspend fun getUserById(id: Long): User?
suspend fun saveUser(user: User): User
}
// commonMain: Implementazione con Ktor + SQLDelight
class UserRepositoryImpl(
private val httpClient: HttpClient,
private val database: AppDatabase
) : UserRepository {
override suspend fun getUsers(): List<User> {
return try {
// Prima controlla il database locale
val cached = database.userQueries.selectAll().executeAsList()
if (cached.isNotEmpty()) {
cached.map { it.toDomain() }
} else {
// Poi scarica dalla rete e salva
val remote = httpClient.get("$BASE_URL/users").body<List<UserDto>>()
remote.forEach { database.userQueries.insert(it.toEntity()) }
remote.map { it.toDomain() }
}
} catch (e: Exception) {
// Fallback al cache anche se la rete fallisce
database.userQueries.selectAll().executeAsList().map { it.toDomain() }
}
}
}
Enterprise Adoption Statistics (2026)
According to Kotlin ecosystem data updated to Q1 2026:
- KMP Adoption in Fortune 500 Companies: 18% (it was 7% in 2023), with the majority in fintech, e-commerce, and B2B enterprise apps.
- Main use cases: sharing business logic between Android and iOS (82%), JVM/Android backend sync (45%), desktop apps (12%).
- Notable companies: Cash App (Block), VMware, Philips, Touchlab, and many SMEs European tech companies use KMP in production.
- Time to value: teams report a 30-40% reduction in time implementation of features after the first 3 months of adoption.
Considerations for Adoption into a Team
Before adopting KMP, consider these practical factors:
- Team skills: KMP requires developers who know Kotlin. Ideally, the Android team brings KMP to iOS, not the other way around.
- Gradle learning curve: the KMP build system with Kotlin Multiplatform Gradle Plugin has a steep learning curve. Invest time in understanding source sets before starting.
- Library compatibility: not all Java/Android libraries are compatible with Kotlin/Native (iOS). Always check KMP compatibility before adding a dependency.
- Build time: KMP projects have longer build times than apps single-platform, especially for iOS (Kotlin/Native compilation). A well configured CI/CD with caching and essential.
Conclusions and Next Steps
Kotlin Multiplatform in 2026 is a mature, stable platform with an ecosystem of libraries enterprise quality. It's not the right solution for everyone — if your team is React-first, React Native or Expo make more sense — but for Android-first teams that want to port code on iOS idiomatically, KMP has become the go-to professional choice.
The next article shows how Set up your first KMP project from scratch: source set structure, Gradle version catalog, first expect/actual functions, and integration with Android Studio for a productive development workflow.
Series: Kotlin Multiplatform — One Codebase, All Platforms
- Article 1 (this): KMP in 2026 — Architecture, Establishment and Ecosystem
- Article 2: Configure Your First KMP Project — Android, iOS and Desktop
- Article 3: Shared Module Architecture — expect/actual, Interfaces and DI
- Article 4: Multiplatform Networking with Ktor Client
- Article 5: Multiplatform Persistence with SQLDelight
- Article 6: Compose Multiplatform — Shared UI on Android and iOS
- Article 7: State Management KMP — ViewModel and Kotlin Flows
- Article 8: KMP Testing — Unit Test, Integration Test and UI Test
- Article 9: Swift Export — Idiomatic Interop with iOS
- Article 10: CI/CD for KMP Projects — GitHub Actions and Fastlane
- Article 11: Case Study — Fintech App with KMP in Production







