Kotlin Multiplatform Mobile — co to je, klíčové pojmy a architektura KMM

Co je Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — je technologie, která umožňuje psát společnou obchodní logiku mobilní aplikace v Kotlinu a používat ji na iOS a Android bez duplikování kódu. Na rozdíl od Ionic nebo Cordova KMM nevykresluje rozhraní ve WebView — UI zůstává plně nativní a píše se ve SwiftUI (iOS) a Jetpack Compose (Android).

KMM byl oznámen společností JetBrains v roce 2019 jako součást strategie Kotlin Multiplatform. Klíčový rozdíl oproti jiným cross-platform řešením — framework se nesnaží sjednotit UI, ale zaměřuje se na sdílení právě toho kódu, který je skutečně stejný pro obě platformy: síťových požadavků, datových modelů, validace formulářů, obchodních pravidel a práce s databázemi.

Podle JetBrains Developer Survey (2025) používá KMM 14% mobilních vývojářů a tento ukazatel roste o 5% ročně. Technologii si vybírají společnosti s vysokými nároky na výkon a nativní uživatelský zážitek, pro které jsou hybridní řešení nepřijatelná.

Architektura KMM: shared modul a platformové implementace

Architektura KMM se skládá ze tří modulů: shared (společný kód v Kotlinu), iosApp (nativní iOS aplikace ve Swiftu) a androidApp (nativní Android aplikace v Kotlinu). Shared modul je kompilován do JAR pro Android a do univerzálního frameworku (Apple Framework) pro iOS.

Shared modul: co se vkládá do společného kódu

Do shared modulu vstupují všechny vrstvy nezávislé na platformě: síťová vrstva na Ktor Client, datové modely se serializací přes kotlinx.serialization, repozitáře pro správu dat, validace formulářů a obchodní pravidla (například výpočet ceny dopravy nebo kontrola přístupových práv).

Shared modul používá Gradle Multiplatform Plugin a obsahuje tři sady zdrojů: commonMain (společný kód), androidMain (implementace specifické pro Android) a iosMain (implementace specifické pro iOS). Kompilátor Kotlin/Native převádí společný kód na nativní knihovnu pro iOS, která se připojuje k projektu Swift přes XCFramework.

Platformové moduly

Android modul — je standardní Android aplikace v Kotlinu s Jetpack Compose nebo ViewBinding. Shared modul se připojuje jako běžná závislost Gradle a všechny třídy z commonMain jsou přímo dostupné.

iOS modul — je projekt Xcode ve Swiftu nebo Objective-C. Shared modul se připojuje přes CocoaPods, Swift Package Manager nebo XCFramework. Kotlin/Native generuje Objective-C hlavičky pro export typů Kotlin, čímž je zpřístupňuje ze Swiftu.

Mechanismus expect/actual v KMM

expect/actual — je mechanismus Kotlin Multiplatform, který umožňuje deklarovat API ve společném kódu (expect declaration) a poskytnout jeho implementaci zvlášť pro každou platformu (actual declaration). Kompilátor hlídá, aby actual existoval pro každou cílovou platformu.

Typické scénáře použití expect/actual: získání aktuálního času s ohledem na časové pásmo, práce s SharedPreferences (Android) / UserDefaults (iOS), kryptografické funkce a generování UUID. Na každé platformě se používá vlastní systémové API.

Bez expect/actual by nebylo možné mít jednotný kód obchodní logiky, protože API pro práci se souborovým systémem, sítí a úložištěm se liší mezi iOS a Android na úrovni systémových volání. Mechanismus zaručuje, že vývojář nezapomene implementovat platformovou část.

Pro platformová volání, jako je práce s kamerou nebo biometrií, nabízí KMM knihovnu expect/actual v kombinaci s pluginy podobnými Cordově, ale v Kotlin/Native. JetBrains také vydala knihovnu kotlinx-datetime, která abstrahuje práci s daty.

Příklady kódu v KMM

Podívejme se na základní strukturu projektu KMM s deklarací expect funkce pro generování UUID a její implementací pro iOS a Android.

// commonMain — společná deklarace
expect fun generateUUID(): String

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

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

Ve společném kódu se deklaruje expect fun generateUUID(). Pro Android se používá java.util.UUID, pro iOS — NSUUID z frameworku Foundation. Ve zbytku kódu shared modulu je tato funkce volána bez ohledu na platformu.

Příklad síťového požadavku s použitím Ktor Client ve společném kódu:

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())
    }
}

Tento kód funguje na obou platformách beze změn. Ktor Client automaticky používá OkHttp na Androidu a NSURLSession na iOS, bez dodatečné konfigurace. JSON serializace přes kotlinx.serialization je také cross-platform.

Srovnání KMM s Flutter a React Native

KMM zaujímá jedinečnou pozici mezi cross-platform technologiemi, protože se nesnaží nahradit nativní UI na rozdíl od Flutter a React Native. KMM — je řešení pro sdílení logiky, nikoli pro sjednocení rozhraní.

Hlavní výhoda KMM — plná kontrola nad UI. Pokud má aplikace vypadat a chovat se nativně na každé platformě (například používat iOS TabBar a Android BottomNavigation s platformovými animacemi), je KMM jediné cross-platform řešení, které to zajišťuje bez obcházení.

Nevýhoda — tým musí současně ovládat Kotlin, Swift, Jetpack Compose a SwiftUI, což komplikuje nábor. Flutter a React Native vyžadují znalost jednoho jazyka a jednoho frameworku.

Výhody a obtíže zavedení KMM

Kotlin Multiplatform Mobile — je výkonná technologie, ale její zavedení vyžaduje vyvážený přístup. Podívejme se na klíčové výhody a typické obtíže, se kterými se týmy potýkají.

Výhody KMM

První a hlavní výhoda — snižení duplicity kódu. Podle JetBrains Case Studies (2024) týmy, které zavedly KMM, snižují objem duplicitního kódu o 60–80% pro síťovou vrstvu a o 40–50% pro obchodní logiku celkově. To přímo ovlivňuje rychlost vývoje a počet chyb.

Druhá výhoda — výkon na úrovni nativních aplikací. Na rozdíl od hybridních frameworků KMM nepřidává vrstvy abstrakce mezi UI a systém. Kód obchodní logiky se provádí stejně rychle, jako kdyby byl napsán ve Swiftu nebo Kotlinu pro každou platformu zvlášť.

Obtíže zavedení

Hlavní obtíž — kvalifikace týmu. Vývojáři musí znát Kotlin (pro shared modul), stejně jako Swift a Jetpack Compose (pro UI). Najít univerzálního specialistu je obtížné, proto se obvykle vytváří tým z Android a iOS vývojářů, kteří společně spravují shared modul.

Druhá obtíž — nástroje. KMM vyžaduje konfiguraci Gradle, CocoaPods nebo Swift Package Manager, stejně jako integraci s Xcode. V raných fázích projektu jsou časté problémy s konfigurací sestavení, zejména při práci s C knihovnami.

Třetí obtíž — ladění. Když se chyba objeví na rozhraní Kotlin/Native a Swift, je určení její příčiny obtížnější než v monolitické aplikaci. JetBrains neustále vylepšuje nástroje pro ladění, ale v praxi musí týmy věnovat až 20% času infrastrukturním úkolům.