Kotlin Multiplatform: Was es ist, shared module und expect/actual

Was ist Kotlin Multiplatform?

Kotlin Multiplatform ist eine Cross-Compilation-Technologie, die es ermöglicht, gemeinsamen Code in Kotlin zu schreiben und für verschiedene Plattformen zu kompilieren: JVM (Android), LLVM (iOS, macOS, watchOS), JavaScript (Web) und native Binärdateien (Linux, Windows). KMP ist kein UI-Framework — es löst das Problem der Wiederverwendung von Geschäftslogik, nicht von Oberflächen.

Die KMP-Architektur ist um ein shared module herum aufgebaut — ein Gradle-Modul, das commonMain mit plattformunabhängigem Code und source sets für jedes Ziel (androidMain, iosMain, desktopMain) enthält. Laut JetBrains-Daten für 2025 verwenden über 40% der neuen Kotlin-Projekte KMP, um Code zwischen Plattformen zu teilen.

Kotlin Multiplatform Mobile (KMM) — der frühere Name für das mobile Szenario iOS+Android. Seit Kotlin 2.1+ wurde der Begriff KMM durch Kotlin Multiplatform ersetzt, da die Technologie über die mobile Entwicklung hinausgegangen ist. Netflix, McDonald's und VMware verwenden KMP in der Produktion, um Code zwischen mobilen Anwendungen zu teilen.

Expect/actual-Mechanismus: Architektur

Expect/actual — der Schlüsselmechanismus von KMP für die Arbeit mit plattformspezifischem Code. In commonMain wird eine expect-Deklaration (Funktion, Klasse, Eigenschaft) deklariert, und in jedem plattformspezifischen source set (androidMain, iosMain) wird eine actual-Implementierung bereitgestellt. Der Compiler prüft, ob für jedes expect ein actual auf jeder Zielplattform existiert.

// commonMain — Plattform-API-Deklaration
expect fun getPlatformName(): String

expect class PlatformContext(val appVersion: String)

// androidMain — actual für Android
actual fun getPlatformName(): String = "Android \${Build.VERSION.SDK_INT}"

// iosMain — actual für iOS
actual fun getPlatformName(): String =
    UIDevice.currentDevice.systemName

Die source set-Hierarchie in KMP ermöglicht die Erstellung von Zwischenebenen: zum Beispiel iosArm64Main (physische iOS-Geräte) und iosSimulatorArm64Main (Simulator) mit gemeinsamem iosMain. Code aus commonMain ist für alle Plattformen verfügbar, während Code aus iosMain nur für iOS-Ziele verfügbar ist. Dies reduziert Duplikate, wenn die Implementierung nicht für jede Plattform, sondern für eine Gruppe von Plattformen unterschiedlich ist.

In der Praxis wird expect/actual verwendet für: Zugriff auf lokalen Speicher (SharedPreferences vs NSUserDefaults), Netzwerk (HttpEngine pro Plattform), Dateisystemzugriff, Kryptographie und Analytik. JetBrains empfiehlt, die Anzahl der expect/actual-Deklarationen zu minimieren und so viel Code wie möglich nach commonMain zu verschieben.

Shared module: Struktur und Gradle

Shared module — ein standardmäßiges Gradle-Modul mit dem Plugin org.jetbrains.kotlin.multiplatform. Es enthält gemeinsamen Code in src/commonMain/kotlin/ und plattformspezifische Implementierungen in src/androidMain/kotlin/ und src/iosMain/kotlin/. Ein KMP-Projekt enthält auch androidApp und iosApp, die vom shared module abhängen.

// build.gradle.kts — shared module
plugins {
    kotlin("multiplatform")
    id("com.android.library")
}

kotlin {
    androidTarget()
    
    listOf(
        iosX64(),
        iosArm64(),
        iosSimulatorArm64()
    ).forEach {
        it.binaries.framework {
            baseName = "shared"
            isStatic = true
        }
    }

    sourceSets {
        val commonMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-core:3.1.0")
                implementation("org.jetbrains.kotlinx:kotlinx-serialization-json:1.7.3")
            }
        }
        val androidMain by getting {
            dependencies {
                implementation("io.ktor:ktor-client-okhttp:3.1.0")
            }
        }
        val iosMain by creating {
            dependencies {
                implementation("io.ktor:ktor-client-darwin:3.1.0")
            }
        }
    }
}

Die Gradle-Konfiguration für KMP erfordert die explizite Deklaration von iOS-Zielen — x64 (Intel-Simulator), arm64 (physische Geräte) und simulatorArm64 (Apple Silicon-Simulator). Für jedes Ziel wird ein separates Apple-Framework generiert. Das Plugin kotlin("multiplatform") konfiguriert automatisch die Kompilierung für JVM und LLVM basierend auf den deklarierten Zielen.

Ktor und kotlinx.serialization — Standard-KMP-Bibliotheken, die gemeinsamen Code unterstützen. Ktor bietet einen HTTP-Client mit Engines für jede Plattform (OkHttp für Android, Darwin für iOS). kotlinx.serialization funktioniert auf allen Plattformen ohne expect/actual dank seiner Multiplattform-Implementierung in commonMain.

iOS-Integration über Kotlin/Native

Kotlin/Native — ein Kotlin-Compiler für nativen Code über LLVM. Für iOS wird das shared module in ein Apple-Framework (.framework) kompiliert, das über Xcode verbunden wird. Das Aufrufen von gemeinsamem Code aus Swift/Objective-C erfolgt über generierte Objective-C-Header, daher muss die shared module-API mit Objective-C kompatibel sein.

Einschränkungen der iOS-Integration: Kotlin-Sammlungen (List, Map) werden in NSArray/NSDictionary konvertiert. Funktionen mit Standardparametern werden nicht exportiert — Überladungen sind erforderlich. Für suspend-Funktionen werden callback-basierte Methoden mit @ObjCName und async/await-Unterstützung ab Kotlin 2.0+ generiert.

// iOS-App: Aufruf des shared module aus Swift
import shared

class ViewModel: ObservableObject {
    let repository = UserRepository()
    
    func loadUsers() {
        repository.fetchUsers(completionHandler: { result, error in
            if let users = result as? [User] {
                print("Users: \(users.count)")
            }
        })
    }
}

Die Integration des shared module in Xcode erfolgt über embed-and-framework — das generierte .xcframework wird zum Xcode-Projekt hinzugefügt. Das Gradle-Plugin kann das Framework während des Builds über embedAndSignAppleFrameworkForXcode automatisch aktualisieren. Zum Testen auf dem Simulator reicht eine iosSimulatorArm64- oder iosX64-Binärdatei aus.

KMP vs Flutter vs React Native

Die Wahl zwischen KMP, Flutter und React Native hängt von der Priorität ab: Code-Wiederverwendung oder vollständige Cross-Plattform. KMP bietet native UI auf jeder Plattform, benötigt aber zwei Codebasen für die Oberfläche. Flutter und React Native verwenden eine einheitliche UI, opfern aber die Nativeität.

Wann KMP wählen: Das Projekt benötigt eine leistungsstarke UI (Spiele, Karten, Animationen), vorhandener nativer Code muss wiederverwendet werden, das Team kennt bereits Kotlin und native Plattformen. Wann Flutter/RN wählen: MVP oder Startup mit begrenztem Budget, Team mit einem Profil, die UI erfordert keine tiefgehende native Anpassung.

KMP-Werkzeuge und Bibliotheken

Das KMP-Werkzeug-Ökosystem umfasst Bibliotheken für alle Anwendungsschichten: Netzwerk (Ktor), Serialisierung (kotlinx.serialization), Datenbank (SQLDelight), Navigation (Decompose), DI (Koin) und Datenspeicherung (multiplatform-settings). JetBrains unterstützt Compose Multiplatform — ein Kotlin-UI-Framework, das auf allen Plattformen läuft.

// KMP-Repository mit SQLDelight + Ktor
class UserRepository(
    private val httpClient: HttpClient,
    private val db: AppDatabase
) {
    suspend fun syncUsers(): List<User> {
        val remote = httpClient.get("https://api.example.com/users")
            .body<List<UserDto>>()
        
        db.userQueries.replaceAll(remote.map { it.toDomain() })
        
        return db.userQueries.selectAll().executeAsList()
    }
}

Compose Multiplatform — ein UI-Framework für KMP basierend auf Jetpack Compose. Es ermöglicht das Schreiben von Oberflächen in Kotlin für Android, iOS, Desktop und Web. Im Jahr 2025 erreichte Compose Multiplatform den stabilen Status für Android und Desktop; das iOS-Ziel befindet sich in der Beta. Für Produktionsprojekte mit nativer UI bleibt der Vorteil von KMP der Hauptunterschied zu Flutter.