Kotlin Multiplatform Mobile — co to jest, kluczowe pojęcia i architektura KMM

Czym jest Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — to technologia, która pozwala pisać wspólną logikę biznesową aplikacji mobilnej w Kotlin i używać jej na iOS i Android bez powielania kodu. W przeciwieństwie do Ionic czy Cordova, KMM nie renderuje interfejsu w WebView — UI pozostaje w pełni natywny i jest pisany w SwiftUI (iOS) i Jetpack Compose (Android).

KMM został ogłoszony przez JetBrains w 2019 roku jako część strategii Kotlin Multiplatform. Kluczowa różnica w porównaniu z innymi rozwiązaniami wieloplatformowymi — framework nie próbuje ujednolicać UI, ale koncentruje się na współdzieleniu właśnie tego kodu, który jest naprawdę taki sam dla obu platform: zapytań sieciowych, modeli danych, walidacji formularzy, reguł biznesowych i pracy z bazami danych.

Według JetBrains Developer Survey (2025), KMM jest używany przez 14% programistów mobilnych, a wskaźnik ten rośnie o 5% rocznie. Technologię wybierają firmy z wysokimi wymaganiami dotyczącymi wydajności i natywnego doświadczenia użytkownika, dla których hybrydowe rozwiązania są nie do przyjęcia.

Architektura KMM: shared moduł i implementacje platformowe

Architektura KMM składa się z trzech modułów: shared (wspólny kod w Kotlin), iosApp (natywna aplikacja iOS w Swift) i androidApp (natywna aplikacja Android w Kotlin). Shared moduł jest kompilowany do JAR dla Androida i do uniwersalnego frameworka (Apple Framework) dla iOS.

Shared moduł: co trafia do wspólnego kodu

Do shared modułu trafiają wszystkie warstwy niezależne od platformy: warstwa sieciowa na Ktor Client, modele danych z serializacją przez kotlinx.serialization, repozytoria do zarządzania danymi, walidacja formularzy i reguły biznesowe (np. obliczanie kosztu dostawy lub sprawdzanie uprawnień dostępu).

Shared moduł używa Gradle Multiplatform Plugin i zawiera trzy zestawy źródeł: commonMain (wspólny kod), androidMain (implementacje specyficzne dla Androida) i iosMain (implementacje specyficzne dla iOS). Kompilator Kotlin/Native przekształca wspólny kod w natywną bibliotekę dla iOS, która jest podłączana do projektu Swift przez XCFramework.

Moduły platformowe

Moduł Android — to standardowa aplikacja Android w Kotlin z Jetpack Compose lub ViewBinding. Shared moduł jest podłączany jako zwykła zależność Gradle, a wszystkie klasy z commonMain są dostępne bezpośrednio.

Moduł iOS — to projekt Xcode w Swift lub Objective-C. Shared moduł jest podłączany przez CocoaPods, Swift Package Manager lub XCFramework. Kotlin/Native generuje nagłówki Objective-C do eksportu typów Kotlin, czyniąc je dostępnymi z Swift.

Mechanizm expect/actual w KMM

expect/actual — to mechanizm Kotlin Multiplatform, który pozwala zadeklarować API we wspólnym kodzie (expect declaration) i dostarczyć jego implementację osobno dla każdej platformy (actual declaration). Kompilator pilnuje, aby actual istniał dla każdej docelowej platformy.

Typowe scenariusze użycia expect/actual: pobieranie bieżącego czasu z uwzględnieniem strefy czasowej, praca z SharedPreferences (Android) / UserDefaults (iOS), funkcje kryptograficzne i generowanie UUID. Na każdej platformie używany jest własny systemowy API.

Bez expect/actual niemożliwe byłoby posiadanie jednolitego kodu logiki biznesowej, ponieważ API do pracy z systemem plików, siecią i pamięcią masową różnią się między iOS i Android na poziomie wywołań systemowych. Mechanizm gwarantuje, że programista nie zapomni zaimplementować części platformowej.

Dla wywołań platformowych, takich jak praca z kamerą czy biometrią, KMM oferuje bibliotekę expect/actual w połączeniu z wtyczkami, podobnymi do Cordova, ale w Kotlin/Native. JetBrains wydała również bibliotekę kotlinx-datetime, abstrahującą pracę z datami.

Przykłady kodu w KMM

Rozważmy podstawową strukturę projektu KMM z deklaracją expect-funkcji do generowania UUID i jej implementacją dla iOS i Android.

// commonMain — ogólna deklaracja
expect fun generateUUID(): String

// androidMain — implementacja dla Androida
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

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

We wspólnym kodzie deklarowana jest expect fun generateUUID(). Dla Android używany jest java.util.UUID, dla iOS — NSUUID z Foundation framework. W pozostałym kodzie shared modułu ta funkcja jest wywoływana bez uwzględniania platformy.

Przykład zapytania sieciowego z użyciem Ktor Client we wspólnym kodzie:

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

Ten kod działa na obu platformach bez zmian. Ktor Client używa OkHttp pod Android i NSURLSession pod iOS automatycznie, bez dodatkowej konfiguracji. Serializacja JSON przez kotlinx.serialization jest również wieloplatformowa.

Porównanie KMM z Flutter i React Native

KMM zajmuje unikalną pozycję wśród technologii wieloplatformowych, ponieważ nie próbuje zastąpić natywnego UI w przeciwieństwie do Flutter i React Native. KMM — to rozwiązanie do współdzielenia logiki, a nie do ujednolicania interfejsu.

Główna zaleta KMM — pełna kontrola nad UI. Jeśli aplikacja ma wyglądać i zachowywać się jak natywna na każdej platformie (np. używać iOS TabBar i Android BottomNavigation z platformowymi animacjami), KMM — to jedyne wieloplatformowe rozwiązanie zapewniające to bez obejść.

Wadą jest to, że zespół musi znać Kotlin, Swift, Jetpack Compose i SwiftUI jednocześnie, co utrudnia rekrutację. Flutter i React Native wymagają znajomości jednego języka i jednego frameworka.

Zalety i trudności wdrożenia KMM

Kotlin Multiplatform Mobile — to potężna technologia, ale jej wdrożenie wymaga wyważonego podejścia. Rozważmy kluczowe zalety i typowe trudności, z jakimi spotykają się zespoły.

Zalety KMM

Pierwszą i główną zaletą jest zmniejszenie powielania kodu. Według JetBrains Case Studies (2024), zespoły które wdrożyły KMM, zmniejszają ilość powielanego kodu o 60–80% dla warstwy sieciowej i o 40–50% dla logiki biznesowej ogólnie. To bezpośrednio wpływa na szybkość tworzenia i liczbę błędów.

Drugą zaletą jest wydajność na poziomie natywnych aplikacji. W przeciwieństwie do hybrydowych frameworków, KMM nie dodaje warstw abstrakcji między UI a systemem. Kod logiki biznesowej wykonuje się tak samo szybko, jak gdyby był napisany w Swift lub Kotlin dla każdej platformy osobno.

Trudności wdrożenia

Główną trudnością jest kwalifikacja zespołu. Programiści muszą znać Kotlin (dla shared modułu), a także Swift i Jetpack Compose (dla UI). Znalezienie uniwersalnego specjalisty jest trudne, dlatego zwykle tworzy się zespół z programistów Android i iOS, którzy wspólnie prowadzą shared moduł.

Drugą trudnością jest narzędziownia. KMM wymaga konfiguracji Gradle, CocoaPods lub Swift Package Manager, a także integracji z Xcode. Na wczesnych etapach projektu częste są problemy z konfiguracją kompilacji, szczególnie przy pracy z bibliotekami C.

Trzecią trudnością jest debugowanie. Gdy błąd pojawia się na styku Kotlin/Native i Swift, określenie jego przyczyny jest trudniejsze niż w monolitycznej aplikacji. JetBrains stale ulepsza narzędzia debugowania, ale w praktyce zespoły muszą poświęcać do 20% czasu na zadania infrastrukturalne.