Kotlin Multiplatform Mobile — was es ist, Schlüsselkonzepte und KMM-Architektur

Was ist Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) ist eine Technologie, die es ermöglicht, die gemeinsame Geschäftslogik einer mobilen Anwendung in Kotlin zu schreiben und ohne Code-Duplizierung auf iOS und Android zu verwenden. Anders als Ionic oder Cordova rendert KMM die Oberfläche nicht in einem WebView — die Benutzeroberfläche bleibt vollständig nativ und wird in SwiftUI (iOS) und Jetpack Compose (Android) geschrieben.

KMM wurde 2019 von JetBrains als Teil der Kotlin-Multiplatform-Strategie angekündigt. Der Hauptunterschied zu anderen plattformübergreifenden Lösungen besteht darin, dass das Framework nicht versucht, die UI zu vereinheitlichen, sondern sich auf die gemeinsame Nutzung genau des Codes konzentriert, der für beide Plattformen wirklich identisch ist: Netzwerkanfragen, Datenmodelle, Formularvalidierung, Geschäftsregeln und Datenbankoperationen.

Laut der JetBrains Developer Survey (2025) wird KMM von 14 % der mobilen Entwickler verwendet, und diese Zahl wächst jährlich um 5 %. Die Technologie wird von Unternehmen mit hohen Anforderungen an Leistung und native Benutzererfahrung gewählt, für die hybride Lösungen nicht akzeptabel sind.

KMM-Architektur: gemeinsames Modul und Plattformimplementierungen

Die KMM-Architektur besteht aus drei Modulen: shared (gemeinsamer Kotlin-Code), iosApp (native iOS-Anwendung in Swift) und androidApp (native Android-Anwendung in Kotlin). Das gemeinsame Modul wird in ein JAR für Android und ein universelles Framework (Apple Framework) für iOS kompiliert.

Gemeinsames Modul: Was in den gemeinsamen Code kommt

Das gemeinsame Modul enthält alle plattformunabhängigen Schichten: die Netzwerkschicht mit Ktor Client, Datenmodelle mit Serialisierung über kotlinx.serialization, Repositories für die Datenverwaltung, Formularvalidierung und Geschäftsregeln (z. B. Berechnung der Lieferkosten oder Überprüfung von Zugriffsberechtigungen).

Das gemeinsame Modul verwendet das Gradle Multiplatform Plugin und enthält drei Quellsätze: commonMain (gemeinsamer Code), androidMain (Android-spezifische Implementierungen) und iosMain (iOS-spezifische Implementierungen). Der Kotlin/Native-Compiler wandelt den gemeinsamen Code in eine native Bibliothek für iOS um, die über XCFramework mit dem Swift-Projekt verbunden wird.

Plattformmodule

Android-Modul — eine standardmäßige Android-Anwendung in Kotlin mit Jetpack Compose oder ViewBinding. Das gemeinsame Modul wird als normale Gradle-Abhängigkeit eingebunden, und alle Klassen aus commonMain sind direkt zugänglich.

Das iOS-Modul ist ein Xcode-Projekt in Swift oder Objective-C. Das gemeinsame Modul wird über CocoaPods, Swift Package Manager oder XCFramework eingebunden. Kotlin/Native generiert Objective-C-Header für den Export von Kotlin-Typen und macht sie so aus Swift zugänglich.

Der expect/actual-Mechanismus in KMM

expect/actual ist ein Kotlin-Multiplatform-Mechanismus, der es ermöglicht, eine API in gemeinsamem Code zu deklarieren (expect-Deklaration) und ihre Implementierung separat für jede Plattform bereitzustellen (actual-Deklaration). Der Compiler stellt sicher, dass für jede Zielplattform eine actual-Deklaration existiert.

Typische Anwendungsfälle für expect/actual: Abrufen der aktuellen Uhrzeit mit Zeitzone, Arbeiten mit SharedPreferences (Android) / UserDefaults (iOS), kryptografische Funktionen und UUID-Generierung. Jede Plattform verwendet ihre eigene System-API.

Ohne expect/actual wäre es unmöglich, einen einheitlichen Geschäftslogik-Code zu haben, da die APIs für die Arbeit mit Dateisystem, Netzwerk und Speicher auf Systemaufrufebene zwischen iOS und Android unterschiedlich sind. Der Mechanismus stellt sicher, dass der Entwickler nicht vergisst, den plattformspezifischen Teil zu implementieren.

Für Plattformaufrufe wie die Arbeit mit der Kamera oder Biometrie bietet KMM den expect/actual-Mechanismus in Kombination mit Plugins ähnlich wie Cordova, aber auf Kotlin/Native. JetBrains hat auch die Bibliothek kotlinx-datetime veröffentlicht, die die Handhabung von Datum und Zeit abstrahiert.

KMM-Codebeispiele

Betrachten wir die grundlegende Struktur eines KMM-Projekts mit einer expect-Funktionsdeklaration für die UUID-Generierung und ihrer Implementierung für iOS und Android.

// commonMain — gemeinsame Deklaration
expect fun generateUUID(): String

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

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

Im gemeinsamen Code wird expect fun generateUUID() deklariert. Android verwendet java.util.UUID, während iOS NSUUID aus dem Foundation-Framework verwendet. Im übrigen Code des gemeinsamen Moduls wird diese Funktion plattformunabhängig aufgerufen.

Ein Beispiel für eine Netzwerkanfrage mit Ktor Client in gemeinsamem 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())
    }
}

Dieser Code funktioniert auf beiden Plattformen ohne Änderungen. Ktor Client verwendet automatisch OkHttp unter Android und NSURLSession unter iOS, ohne zusätzliche Konfiguration. Die JSON-Serialisierung über kotlinx.serialization ist ebenfalls plattformübergreifend.

Vergleich von KMM mit Flutter und React Native

KMM nimmt eine einzigartige Position unter den plattformübergreifenden Technologien ein, da es im Gegensatz zu Flutter und React Native nicht versucht, die native UI zu ersetzen. KMM ist eine Lösung zum Teilen von Logik, nicht zur Vereinheitlichung der Oberfläche.

Der Hauptvorteil von KMM ist die vollständige Kontrolle über die UI. Wenn eine Anwendung auf jeder Plattform nativ aussehen und sich verhalten muss (z. B. Verwendung von iOS TabBar und Android BottomNavigation mit Plattformanimationen), ist KMM die einzige plattformübergreifende Lösung, die dies ohne Workarounds bietet.

Der Nachteil ist, dass das Team gleichzeitig Kotlin, Swift, Jetpack Compose und SwiftUI beherrschen muss, was die Einstellung erschwert. Flutter und React Native erfordern Kenntnisse einer Sprache und eines Frameworks.

Vorteile und Herausforderungen bei der Einführung von KMM

Kotlin Multiplatform Mobile ist eine leistungsstarke Technologie, aber ihre Einführung erfordert einen ausgewogenen Ansatz. Betrachten wir die wichtigsten Vorteile und typischen Herausforderungen, mit denen Teams konfrontiert sind.

Vorteile von KMM

Der erste und wichtigste Vorteil ist die Reduzierung von Code-Duplizierung. Laut JetBrains-Fallstudien (2024) reduzieren Teams, die KMM eingeführt haben, duplizierten Code um 60–80 % für die Netzwerkschicht und um 40–50 % für die gesamte Geschäftslogik. Dies wirkt sich direkt auf die Entwicklungsgeschwindigkeit und die Anzahl der Fehler aus.

Der zweite Vorteil ist die Leistung auf dem Niveau nativer Anwendungen. Im Gegensatz zu hybriden Frameworks fügt KMM keine Abstraktionsebenen zwischen der UI und dem System hinzu. Der Geschäftslogik-Code wird genauso schnell ausgeführt, als wäre er in Swift oder Kotlin für jede Plattform separat geschrieben.

Herausforderungen bei der Einführung

Die größte Herausforderung ist die Qualifikation des Teams. Entwickler müssen Kotlin (für das gemeinsame Modul) sowie Swift und Jetpack Compose (für die UI) beherrschen. Einen universellen Spezialisten zu finden ist schwierig, daher bestehen Teams in der Regel aus Android- und iOS-Entwicklern, die gemeinsam das gemeinsame Modul betreuen.

Die zweite Herausforderung sind die Werkzeuge. KMM erfordert die Konfiguration von Gradle, CocoaPods oder Swift Package Manager sowie die Integration mit Xcode. In frühen Projektphasen sind Probleme mit der Build-Konfiguration häufig, insbesondere bei der Arbeit mit C-Bibliotheken.

Die dritte Herausforderung ist das Debugging. Wenn ein Fehler an der Schnittstelle von Kotlin/Native und Swift auftritt, ist die Ursachenbestimmung schwieriger als in einer monolithischen Anwendung. JetBrains verbessert kontinuierlich die Debugging-Werkzeuge, aber in der Praxis verbringen Teams bis zu 20 % ihrer Zeit mit Infrastrukturaufgaben.