KMP in 2026: architectuur, oprichting en ecosysteem van Kotlin Multiplatform
Kotlin Multiplatform (KMP) wordt al jaren bestempeld als ‘interessant maar nog niet klaar voor productie". In 2026 is dit verhaal definitief veranderd: KMP heeft volwassenheid bereikt onderneming met stabiele iOS API, Compose Multiplatform stabiel op alle grote platforms, e Snelle export waardoor eindelijk de noodzaak van Objective-C-overbrugging overbodig wordt interoperabiliteit met native Swift-code.
Deze gids geeft een uitgebreid overzicht van het KMP-ecosysteem in 2026: wat er sindsdien is veranderd ten opzichte van voorgaande jaren, hoe het zich verhoudt tot Flutter en React Native, wat is de juiste architectuur voor een platformonafhankelijk project en hoe u kunt beoordelen of KMP de juiste keuze is voor uw gebruiksscenario.
Wat je gaat leren
- KMP-architectuur: gedeelde modules, bronset en platformspecifieke code
- KMP vs Flutter vs React Native: technische vergelijking bijgewerkt naar 2026
- Swift Export en native interoperabiliteit met iOS
- Stel Multiplatform samen: huidige status en beperkingen
- KMP 2026 bibliotheekecosysteem: Ktor, SQLDelight, Koin
- Wanneer kies je voor KMP en wanneer niet?
De kwaliteitssprong in 2025-2026
KMP 1.0 was al stabiel voor het delen van bedrijfslogica, maar had last van belangrijke beperkingen: iOS-integratie vereist automatisch gegenereerde Objective-C-headers (niet erg idiomatisch voor Swift-ontwikkelaars) en Compose Multiplatform hadden nog steeds veel API's in alfa op iOS en desktop.
De belangrijkste veranderingen die tussen 2024 en 2026 hebben plaatsgevonden:
- Swift Export (stabiel in KMP 1.9+): Genereer native Swift API met naamgeving idiomatisch, protocollen, standaardargumenten en geen tussenliggende Objective-C. De ontwikkelaars iOS gebruikt nu Kotlin-code alsof het pure Swift is.
- Componeer Multiplatform 1.7+ (stabiel op iOS): Volledig gedeelde gebruikersinterface Kotlin/Compose op Android, iOS, Desktop (JVM) en Web (Wasm). Platformspecifieke rendering-engines ze zijn nu volwassen en de prestaties zijn zelfs voor complexe apps acceptabel.
- Amper-bouwsysteem (bèta): vereenvoudigd alternatief voor Gradle voor KMP-projecten, met YAML-installatie in plaats van complexe Kotlin DSL.
- Verbeterde gereedschappen: Android Studio Ladybug en later hebben KMP-ondersteuning van wereldklasse met platformonafhankelijke refactoring, foutopsporing op de ingebouwde iOS-simulator en profilering.
Architectuur van een KMP-project
De fundamentele architectuur van KMP is gebaseerd op de scheiding van gedeelde code (commonMain) en platformspecifieke code. Het gaat niet om "alles in één keer schrijven", zoals React Native beloofde, maar om de logica te delen die zinvol is om te delen en te delegeren aan het platform wat is intrinsiek inheems.
// 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)
Het leidende principe: deel zoveel mogelijk, gebruik indien nodig native API's. Normaal gesproken deelt een volwassen KMP-applicatie het volgende:
- 90-95% van de bedrijfslogica (domeinlaag)
- 80-85% van de datalaag (netwerk, persistentie, caching)
- 40-80% van de presentatielaag (afhankelijk of Compose Multiplatform wordt gebruikt)
- 0-20% van de UI-laag (bij gebruik van platformspecifieke native UI)
KMP versus Flutter versus React Native: de vergelijking van 2026
De vraag "welk platformonafhankelijk raamwerk moet ik gebruiken?" heeft in 2026 andere antwoorden dan in 2022. Hier is een eerlijke vergelijking:
// 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
Het belangrijkste verschil: Flutter gebruikt een aangepaste rendering-engine (Impeller) om te tekenen de gehele gebruikersinterface, waardoor visuele consistentie op meerdere platforms wordt gegarandeerd, maar dit gaat ten koste van het ‘native’ uiterlijk van de platform. KMP met native UI ziet er precies zo uit als een native app, omdat VS de componenten eigen aan het platform.
Wanneer moet u voor KMP kiezen?
KMP is de optimale keuze wanneer:
- Het team heeft een sterke Android/Kotlin-expertise en wil die logica naar iOS brengen
- Het ‘native’ aspect van de gebruikersinterface is een niet-onderhandelbare vereiste (bankapps, onderneming)
- U wilt bedrijfslogica delen terwijl u de volledige controle over de platformspecifieke gebruikersinterface behoudt
- Applicatie heeft complexe bedrijfslogica (bij voorkeur te isoleren van UI-problemen)
- Je voegt iOS toe aan een bestaande Android-app zonder alles te herschrijven
Flutter of React Native kan de voorkeur hebben wanneer:
- Het team beschikt over web/React-vaardigheden en wil deze hergebruiken
- U wilt het delen van de gebruikersinterface maximaliseren (niet alleen logica)
- De time-to-market is van cruciaal belang en het team kent Kotlin niet
Swift Export: iOS-interoperabiliteit in 2026
Vóór Swift Export werd gedeelde Kotlin-code via headers aan iOS getoond Automatisch gegenereerde Objective-C. Het resultaat was een API zoals deze:
// 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 vertaalt Kotlin-coroutines automatisch naar async/await Snel,
dataklassen in Swift-structuur (met automatische gelijkstelling), verzegelde klassen in Swift-enums,
en stromen in AsyncSequence. Het resultaat is dat iOS-ontwikkelaars de Kotlin API gebruiken
alsof het in Swift is geschreven.
Stel Multiplatform samen: huidige status
Met Compose Multiplatform (CMP) kunt u de volledige gebruikersinterface delen die in Compose Kotlin is geschreven op Android, iOS, Desktop JVM en Web (via Kotlin/Wasm). In 2026 werd het opgericht op iOS en aanzienlijk verbeterd vergeleken met de eerste bèta's:
// 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)
}
}
}
De Compose UI is identiek op Android en iOS. Rendering maakt gebruik van Skiko (Skia's Kotlin-binding) op iOS in plaats van native UIKit-componenten, wat betekent dat de app een consistent uiterlijk heeft platformonafhankelijk maar niet identiek aan een native SwiftUI-app.
Het KMP-bibliotheekecosysteem in 2026
Een ecosysteem van volwassen bibliotheken is essentieel voor de productiviteit. In 2026 zijn dit de fundamentele bibliotheken voor een 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")
}
}
}
Een compleet voorbeeld: Pattern Repository in KMP
Laten we eens kijken hoe we een eenvoudige repository voor gebruikersbeheer in KMP kunnen implementeren, toont de scheiding tussen gemeenschappelijke en platformspecifieke 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() }
}
}
}
Statistieken over adoptie van ondernemingen (2026)
Volgens Kotlin-ecosysteemgegevens bijgewerkt tot Q1 2026:
- KMP-adoptie in Fortune 500-bedrijven: 18% (was 7% in 2023), met het merendeel in fintech-, e-commerce- en B2B-ondernemingsapps.
- Belangrijkste gebruiksscenario's: bedrijfslogica delen tussen Android en iOS (82%), JVM/Android backend-synchronisatie (45%), desktop-apps (12%).
- Opmerkelijke bedrijven: Cash App (Block), VMware, Philips, Touchlab en vele MKB-bedrijven Europese technologiebedrijven gebruiken KMP in de productie.
- Tijd om te waarderen: teams rapporteren een tijdsbesparing van 30-40% implementatie van functies na de eerste drie maanden van adoptie.
Overwegingen bij adoptie in een team
Houd rekening met deze praktische factoren voordat u KMP adopteert:
- Teamvaardigheden: KMP vereist ontwikkelaars die Kotlin kennen. Idealiter brengt het Android-team KMP naar iOS, en niet andersom.
- Graduele leercurve: het KMP-bouwsysteem met Kotlin Multiplatform Gradle Plugin heeft een steile leercurve. Investeer tijd in begrip broninstellingen voordat u begint.
- Compatibiliteit met bibliotheek: niet alle Java/Android-bibliotheken zijn compatibel met Kotlin/Native (iOS). Controleer altijd de KMP-compatibiliteit voordat u een afhankelijkheid toevoegt.
- Bouwtijd: KMP-projecten hebben langere bouwtijden dan apps single-platform, vooral voor iOS (Kotlin/Native-compilatie). Een goed geconfigureerde CI/CD met caching en essentieel.
Conclusies en volgende stappen
Kotlin Multiplatform in 2026 is een volwassen, stabiel platform met een ecosysteem van bibliotheken ondernemingskwaliteit. Het is niet voor iedereen de juiste oplossing. Als uw team React-first is, React Native of Expo zijn logischer, maar voor Android-first-teams die code willen porten op iOS is KMP idiomatisch de professionele keuze geworden.
Het volgende artikel laat zien hoe Zet uw eerste KMP-project helemaal opnieuw op: bronsetstructuur, Gradle-versiecatalogus, eerste verwachte/werkelijke functies en integratie met Android Studio voor een productieve ontwikkelingsworkflow.
Serie: Kotlin Multiplatform – Eén Codebase, alle platforms
- Artikel 1 (dit): KMP in 2026 — Architectuur, vestiging en ecosysteem
- Artikel 2: Configureer uw eerste KMP-project — Android, iOS en desktop
- Artikel 3: Gedeelde modulearchitectuur – verwacht/actueel, interfaces en DI
- Artikel 4: Multiplatformnetwerken met Ktor Client
- Artikel 5: Volharding op meerdere platforms met SQLDelight
- Artikel 6: Stel multiplatform samen – gedeelde gebruikersinterface op Android en iOS
- Artikel 7: Staatsbeheer KMP — ViewModel en Kotlin Flows
- Artikel 8: KMP-testen – Unittest, Integratietest en UI-test
- Artikel 9: Swift Export – Idiomatische interoperabiliteit met iOS
- Artikel 10: CI/CD voor KMP-projecten — GitHub Actions en Fastlane
- Artikel 11: Case Study — Fintech-app met KMP in productie







