Kotlin Multiplatform Mobile — vad är det, nyckelbegrepp och arkitektur för KMM

Vad är Kotlin Multiplatform Mobile?

Kotlin Multiplatform Mobile (KMM) — är en teknologi som gör det möjligt att skriva den gemensamma affärslogiken för en mobilapp i Kotlin och använda den på iOS och Android utan att duplicera kod. Till skillnad från Ionic eller Cordova renderar KMM inte gränssnittet i WebView — UI förblir helt inbyggt och skrivs i SwiftUI (iOS) och Jetpack Compose (Android).

KMM tillkännagavs av JetBrains 2019 som en del av strategin Kotlin Multiplatform. Den viktigaste skillnaden jämfört med andra cross-platform-lösningar — ramverket försöker inte ena UI, utan fokuserar på att dela just den kod som verkligen är densamma för båda plattformarna: nätverksförfrågningar, datamodeller, formulärvalidering, affärsregler och arbete med databaser.

Enligt JetBrains Developer Survey (2025) används KMM av 14% av mobila utvecklare, och denna siffra växer med 5% årligen. Teknologin väljs av företag med höga krav på prestanda och inbyggd användarupplevelse, för vilka hybridlösningar är oacceptabla.

KMM-arkitektur: shared-modul och plattformsimplementeringar

KMM-arkitekturen består av tre moduler: shared (gemensam kod i Kotlin), iosApp (inbyggd iOS-app i Swift) och androidApp (inbyggd Android-app i Kotlin). Shared-modulen kompileras till JAR för Android och till ett universellt ramverk (Apple Framework) för iOS.

Shared-modul: vad som förs in i den gemensamma koden

I shared-modulen ingår alla plattformsoberoende lager: nätverkslagret med Ktor Client, datamodeller med serialisering via kotlinx.serialization, datalager för datahantering, formulärvalidering och affärsregler (till exempel beräkning av fraktkostnad eller kontroll av åtkomsträttigheter).

Shared-modulen använder Gradle Multiplatform Plugin och innehåller tre källkodsuppsättningar: commonMain (gemensam kod), androidMain (Android-specifika implementeringar) och iosMain (iOS-specifika implementeringar). Kompilatorn Kotlin/Native omvandlar den gemensamma koden till ett inbyggt bibliotek för iOS, som ansluts till Swift-projektet via XCFramework.

Plattformsmoduler

Android-modulen — är en standard Android-app i Kotlin med Jetpack Compose eller ViewBinding. Shared-modulen ansluts som ett vanligt Gradle-beroende och alla klasser från commonMain är direkt tillgängliga.

iOS-modulen — är ett Xcode-projekt i Swift eller Objective-C. Shared-modulen ansluts via CocoaPods, Swift Package Manager eller XCFramework. Kotlin/Native genererar Objective-C-rubriker för export av Kotlin-typer, vilket gör dem tillgängliga från Swift.

Mekanismen expect/actual i KMM

expect/actual — är en Kotlin Multiplatform-mekanism som gör det möjligt att deklarera ett API i gemensam kod (expect declaration) och tillhandahålla dess implementering separat för varje plattform (actual declaration). Kompilatorn övervakar att actual finns för varje målplattform.

Typiska användningsscenarier för expect/actual: hämta aktuell tid med hänsyn till tidszon, arbeta med SharedPreferences (Android) / UserDefaults (iOS), kryptografiska funktioner och generering av UUID. På varje plattform används det egna system-API:et.

Utan expect/actual skulle det vara omöjligt att ha enhetlig affärslogikkod, eftersom API:erna för att arbeta med filsystem, nätverk och lagring skiljer sig mellan iOS och Android på nivån av systemanrop. Mekanismen garanterar att utvecklaren inte glömmer att implementera plattformsdelen.

För plattformsanrop som att arbeta med kamera eller biometri erbjuder KMM expect/actual-biblioteket i kombination med plugin-program som liknar Cordova, men i Kotlin/Native. JetBrains har också släppt biblioteket kotlinx-datetime som abstraherar arbete med datum.

Kodexempel i KMM

Låt oss titta på grundstrukturen för ett KMM-projekt med deklaration av en expect-funktion för att generera UUID och dess implementering för iOS och Android.

// commonMain — gemensam deklaration
expect fun generateUUID(): String

// androidMain — implementering för Android
actual fun generateUUID(): String {
    return java.util.UUID.randomUUID().toString()
}

// iosMain — implementering för iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

I den gemensamma koden deklareras expect fun generateUUID(). För Android används java.util.UUID, för iOS — NSUUID från Foundation-ramverket. I resten av koden i shared-modulen anropas denna funktion utan hänsyn till plattform.

Exempel på nätverksförfrågan med Ktor Client i gemensam kod:

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

Denna kod fungerar på båda plattformarna utan ändringar. Ktor Client använder automatiskt OkHttp på Android och NSURLSession på iOS, utan extra konfiguration. JSON-serialisering via kotlinx.serialization är också cross-platform.

Jämförelse av KMM med Flutter och React Native

KMM intar en unik position bland cross-platform-teknologier, eftersom det inte försöker ersätta det inbyggda UI:t till skillnad från Flutter och React Native. KMM — är en lösning för att dela logik, inte för att ena gränssnittet.

Den främsta fördelen med KMM — fullständig kontroll över UI. Om appen måste se ut och bete sig inbyggt på varje plattform (till exempel använda iOS TabBar och Android BottomNavigation med plattformsanimationer), är KMM den enda cross-platform-lösningen som säkerställer detta utan kringgående lösningar.

Nackdel — teamet måste samtidigt kunna Kotlin, Swift, Jetpack Compose och SwiftUI, vilket försvårar rekrytering. Flutter och React Native kräver kunskap om ett språk och ett ramverk.

Fördelar och utmaningar med att implementera KMM

Kotlin Multiplatform Mobile — är en kraftfull teknologi, men dess implementering kräver ett balanserat tillvägagångssätt. Låt oss titta på de viktigaste fördelarna och typiska utmaningar som team står inför.

Fördelar med KMM

Den första och viktigaste fördelen — minskning av kodduplicering. Enligt JetBrains Case Studies (2024) minskar team som implementerat KMM mängden duplicerad kod med 60–80% för nätverkslagret och med 40–50% för affärslogiken som helhet. Detta påverkar direkt utvecklingshastigheten och antalet buggar.

Den andra fördelen — prestanda på nivån av inbyggda appar. Till skillnad från hybridramverk lägger KMM inte till abstraktionslager mellan UI och system. Affärslogikkoden körs lika snabbt som om den hade skrivits i Swift eller Kotlin för varje plattform separat.

Utmaningar med implementering

Den största utmaningen — teamets kompetens. Utvecklare måste kunna Kotlin (för shared-modulen), samt Swift och Jetpack Compose (för UI). Att hitta en universell specialist är svårt, därför bildas vanligtvis ett team av Android- och iOS-utvecklare som gemensamt hanterar shared-modulen.

Den andra utmaningen — verktygen. KMM kräver konfiguration av Gradle, CocoaPods eller Swift Package Manager, samt integration med Xcode. I tidiga projektfaser är problem med byggkonfiguration vanliga, särskilt vid arbete med C-bibliotek.

Den tredje utmaningen — felsökning. När en bugg uppstår i gränssnittet mellan Kotlin/Native och Swift är det svårare att fastställa orsaken än i en monolitisk applikation. JetBrains förbättrar kontinuerligt felsökningsverktygen, men i praktiken måste team lägga upp till 20% av tiden på infrastrukturella uppgifter.