Kotlin Multiplatform Mobile — wat is het, kernbegrippen en architectuur van KMM

Wat is Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — is een technologie waarmee je de gemeenschappelijke bedrijfslogica van een mobiele app in Kotlin kunt schrijven en deze op iOS en Android kunt gebruiken zonder code te dupliceren. In tegenstelling tot Ionic of Cordova rendert KMM de interface niet in WebView — de UI blijft volledig native en wordt geschreven in SwiftUI (iOS) en Jetpack Compose (Android).

KMM werd in 2019 door JetBrains aangekondigd als onderdeel van de Kotlin Multiplatform-strategie. Het belangrijkste verschil met andere cross-platform oplossingen — het framework probeert niet de UI te uniformeren, maar richt zich op het delen van precies die code die echt hetzelfde is voor beide platforms: netwerkverzoeken, datamodellen, formuliervalidatie, bedrijfsregels en werken met databases.

Volgens de JetBrains Developer Survey (2025) wordt KMM gebruikt door 14% van de mobiele ontwikkelaars en dit cijfer groeit met 5% per jaar. De technologie wordt gekozen door bedrijven met hoge eisen aan prestaties en native gebruikerservaring, voor wie hybride oplossingen onacceptabel zijn.

KMM-architectuur: shared-module en platformimplementaties

De KMM-architectuur bestaat uit drie modules: shared (gedeelde code in Kotlin), iosApp (native iOS-app in Swift) en androidApp (native Android-app in Kotlin). De shared-module wordt gecompileerd naar JAR voor Android en naar een universeel framework (Apple Framework) voor iOS.

Shared-module: wat gaat naar de gedeelde code

In de shared-module komen alle platformonafhankelijke lagen: de netwerklaag op Ktor Client, datamodellen met serialisatie via kotlinx.serialization, repositories voor gegevensbeheer, formuliervalidatie en bedrijfsregels (bijvoorbeeld het berekenen van verzendkosten of het controleren van toegangsrechten).

De shared-module gebruikt de Gradle Multiplatform Plugin en bevat drie bronsets: commonMain (gedeelde code), androidMain (Android-specifieke implementaties) en iosMain (iOS-specifieke implementaties). De Kotlin/Native-compiler zet de gedeelde code om in een native bibliotheek voor iOS, die via XCFramework aan het Swift-project wordt gekoppeld.

Platformmodules

De Android-module — is een standaard Android-app in Kotlin met Jetpack Compose of ViewBinding. De shared-module wordt gekoppeld als een gewone Gradle-afhankelijkheid en alle klassen uit commonMain zijn direct beschikbaar.

De iOS-module — is een Xcode-project in Swift of Objective-C. De shared-module wordt gekoppeld via CocoaPods, Swift Package Manager of XCFramework. Kotlin/Native genereert Objective-C-headers voor het exporteren van Kotlin-types, waardoor ze toegankelijk zijn vanuit Swift.

Het expect/actual-mechanisme in KMM

expect/actual — is een Kotlin Multiplatform-mechanisme waarmee je een API in gedeelde code kunt declareren (expect declaration) en de implementatie ervan apart voor elk platform kunt leveren (actual declaration). De compiler controleert of actual bestaat voor elk doelplatform.

Typische gebruiksscenario's van expect/actual: het ophalen van de huidige tijd met tijdzone, werken met SharedPreferences (Android) / UserDefaults (iOS), cryptografische functies en het genereren van UUID. Op elk platform wordt de eigen systeem-API gebruikt.

Zonder expect/actual zou het onmogelijk zijn om uniforme bedrijfslogica-code te hebben, omdat de API's voor het werken met het bestandssysteem, netwerk en opslag verschillen tussen iOS en Android op het niveau van systeemoproepen. Het mechanisme garandeert dat de ontwikkelaar niet vergeet het platformdeel te implementeren.

Voor platformoproepen zoals werken met de camera of biometrie biedt KMM de expect/actual-bibliotheek in combinatie met plugins vergelijkbaar met Cordova, maar in Kotlin/Native. JetBrains heeft ook de bibliotheek kotlinx-datetime uitgebracht die het werken met datums abstraheert.

Codevoorbeelden in KMM

Laten we de basisstructuur van een KMM-project bekijken met de declaratie van een expect-functie voor het genereren van UUID en de implementatie ervan voor iOS en Android.

// commonMain — gedeelde declaratie
expect fun generateUUID(): String

// androidMain — implementatie voor Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — implementatie voor iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

In de gedeelde code wordt expect fun generateUUID() gedeclareerd. Voor Android wordt java.util.UUID gebruikt, voor iOS — NSUUID uit het Foundation-framework. In de rest van de code van de shared-module wordt deze functie aangeroepen zonder rekening te houden met het platform.

Voorbeeld van een netwerkverzoek met Ktor Client in gedeelde code:

import io.ktor.client.*
import io.ktor.client.request.*
import io.ktor.client.statement.*
import kotlinx.serialization.*
import kotlinx.serialization.json.*

@Serializable
data class User(
    val id: Int,
    val name: String
)

class UserRepository {
    private val client = HttpClient()

    suspend fun getUser(id: Int): User {
        val response: HttpStatement =
            client.get("https://api.example.com/users/$id")
        return Json.decodeFromString(response.bodyAsText())
    }
}

Deze code werkt op beide platforms zonder wijzigingen. Ktor Client gebruikt automatisch OkHttp op Android en NSURLSession op iOS, zonder extra configuratie. JSON-serialisatie via kotlinx.serialization is ook cross-platform.

Vergelijking van KMM met Flutter en React Native

KMM neemt een unieke positie in tussen cross-platform technologieën, omdat het niet probeert de native UI te vervangen in tegenstelling tot Flutter en React Native. KMM — is een oplossing voor het delen van logica, niet voor het uniformeren van de interface.

Het belangrijkste voordeel van KMM — volledige controle over de UI. Als de app er native uit moet zien en zich native moet gedragen op elk platform (bijvoorbeeld het gebruik van iOS TabBar en Android BottomNavigation met platformanimaties), is KMM de enige cross-platform oplossing die dit biedt zonder workarounds.

Nadeel — het team moet tegelijkertijd Kotlin, Swift, Jetpack Compose en SwiftUI beheersen, wat het aannemen bemoeilijkt. Flutter en React Native vereisen kennis van één taal en één framework.

Voordelen en uitdagingen van KMM-implementatie

Kotlin Multiplatform Mobile — is een krachtige technologie, maar de implementatie ervan vereist een evenwichtige aanpak. Laten we de belangrijkste voordelen en typische uitdagingen bekijken waarmee teams worden geconfronteerd.

Voordelen van KMM

Het eerste en belangrijkste voordeel — vermindering van codeduplicatie. Volgens JetBrains Case Studies (2024) verminderen teams die KMM hebben geïmplementeerd de hoeveelheid gedupliceerde code met 60–80% voor de netwerklaag en met 40–50% voor de bedrijfslogica als geheel. Dit heeft direct invloed op de ontwikkelsnelheid en het aantal bugs.

Het tweede voordeel — prestaties op het niveau van native apps. In tegenstelling tot hybride frameworks voegt KMM geen abstractielagen toe tussen de UI en het systeem. De code van de bedrijfslogica wordt net zo snel uitgevoerd als wanneer deze apart in Swift of Kotlin voor elk platform was geschreven.

Uitdagingen bij implementatie

De grootste uitdaging — de kwalificatie van het team. Ontwikkelaars moeten Kotlin kennen (voor de shared-module), evenals Swift en Jetpack Compose (voor de UI). Het vinden van een universele specialist is moeilijk, daarom wordt meestal een team gevormd van Android- en iOS-ontwikkelaars die gezamenlijk de shared-module beheren.

De tweede uitdaging — de tooling. KMM vereist configuratie van Gradle, CocoaPods of Swift Package Manager, evenals integratie met Xcode. In vroege projectfasen komen problemen met build-configuratie vaak voor, vooral bij het werken met C-bibliotheken.

De derde uitdaging — debuggen. Wanneer een bug optreedt op het snijvlak van Kotlin/Native en Swift, is het moeilijker om de oorzaak te achterhalen dan in een monolithische app. JetBrains verbetert voortdurend de debugtools, maar in de praktijk moeten teams tot 20% van hun tijd besteden aan infrastructurele taken.