Kotlin Multiplatform: vad är det, shared module och expect/actual

Vad är Kotlin Multiplatform?

Kotlin Multiplatform — tvärkompileringsteknik som gör det möjligt att skriva gemensam kod i Kotlin och kompilera den för olika plattformar: JVM (Android), LLVM (iOS, macOS, watchOS), JavaScript (Web) och inbyggda binärer (Linux, Windows). KMP är inte ett UI-ramverk — det löser problemet med återanvändning av affärslogik, inte gränssnitt.

Arkitekturen för KMP bygger på shared module — en Gradle-modul som innehåller commonMain med plattformsoberoende kod och source sets för varje mål (androidMain, iosMain, desktopMain). Enligt JetBrains data från 2025 använder mer än 40 % av nya Kotlin-projekt KMP för att dela kod mellan plattformar.

Kotlin Multiplatform Mobile (KMM) — det tidigare namnet för mobila scenariot iOS+Android. Från och med Kotlin 2.1+ har termen KMM ersatts av allmänna Kotlin Multiplatform, eftersom tekniken har överskridit gränserna för mobil utveckling. Netflix, McDonald's och VMware använder KMP i produktion för att dela kod mellan mobila applikationer.

Expect/actual-mekanism: arkitektur

Expect/actual — den viktigaste mekanismen i KMP för att arbeta med plattformskod. I commonMain deklareras en expect-deklaration (funktion, klass, egenskap), och i varje plattformsspecifikt source set (androidMain, iosMain) — actual-implementeringen. Kompilatorn kontrollerar att det för varje expect finns en actual på varje målplattform.

// commonMain — deklaration av plattforms-API
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

Hierarki av source sets i KMP gör det möjligt att skapa mellanliggande nivåer: till exempel iosArm64Main (fysiska iOS-enheter) och iosSimulatorArm64Main (simulator) med gemensam iosMain. Kod från commonMain är tillgänglig för alla plattformar och kod från iosMain endast för iOS-mål. Detta minskar duplicering när implementeringen inte skiljer sig för varje plattform utan för en grupp av plattformar.

I praktiken används expect/actual för: att få lokal lagring (SharedPreferences vs NSUserDefaults), arbete med nätverk (HttpEngine för varje plattform), åtkomst till filsystem, kryptering och analys. JetBrains rekommenderar att man minimerar antalet expect/actual och flyttar så mycket kod som möjligt till commonMain.

Shared module: struktur och Gradle

Shared module — en standard Gradle-modul med plugin `org.jetbrains.kotlin.multiplatform`. Den innehåller gemensam kod i `src/commonMain/kotlin/` och plattformsimplementeringar i `src/androidMain/kotlin/` och `src/iosMain/kotlin/`. Ett KMP-projekt ansluter också `androidApp` och `iosApp`, som är beroende av shared module.

// 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")
            }
        }
    }
}

Konfiguration av Gradle för KMP kräver explicit angivelse av iOS-mål — x64 (Intel-simulator), arm64 (fysiska enheter) och simulatorArm64 (Apple Silicon-simulator). För varje mål genereras ett separat Apple framework. Plugin `kotlin("multiplatform")` konfigurerar automatiskt kompilering för JVM och LLVM beroende på de deklarerade målen.

Ktor och kotlinx.serialization — standard KMP-bibliotek som stöder gemensam kod. Ktor tillhandahåller en HTTP-klient med motorer för varje plattform (OkHttp för Android, Darwin för iOS). kotlinx.serialization fungerar på vilken plattform som helst utan expect/actual tack vare multiplattformsimplementeringen i commonMain.

Integrering med iOS via Kotlin/Native

Kotlin/Native — kompilatorn från Kotlin till inbyggd kod via LLVM. För iOS kompileras shared module till Apple framework (.framework) som ansluts via Xcode. Anrop av gemensam kod från Swift/Objective-C sker via genererade Objective-C-headers, därför måste shared modules API vara kompatibelt med Objective-C.

Begränsningar för iOS-integrering: Kotlin-collections (List, Map) konverteras till NSArray/NSDictionary. Funktioner med standardparametrar exporteras inte — overloads behövs. För suspend-funktioner genereras callback-baserade metoder med `@ObjCName` och async/await-stöd från Kotlin 2.0+.

// iOS-app: anropa shared module från 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)")
            }
        })
    }
}

Integrering av shared module i Xcode sker via embed-and-framework — den genererade `.xcframework` läggs till i Xcode-projektet. Gradle-plugin kan automatiskt uppdatera framework vid bygge via embedAndSignAppleFrameworkForXcode. För testning på simulatorn räcker iosSimulatorArm64 eller iosX64-binär.

KMP vs Flutter vs React Native

Valet mellan KMP, Flutter och React Native beror på prioritet: återanvändning av logik eller full multiplattform. KMP ger inbyggt UI på varje plattform men kräver två kodbaser för gränssnittet. Flutter och React Native använder ett enhetligt UI men offrar inbyggdhet.

När ska man välja KMP: projektet kräver högpresterande UI (spel, kartor, animationer), befintlig inbyggd kod måste återanvändas, teamet kan redan Kotlin och inbyggda plattformar. När ska man välja Flutter/RN: MVP eller startup med begränsad budget, team med en profil, UI kräver inte djup inbyggd anpassning.

KMP-verktyg och bibliotek

Ekosystemet av KMP-verktyg inkluderar bibliotek för alla lager av applikationen: nätverk (Ktor), serialisering (kotlinx.serialization), databas (SQLDelight), navigering (Decompose), DI (Koin) och datalagring (multiplatform-settings). JetBrains stöder Compose Multiplatform — ett UI-ramverk i Kotlin som fungerar på alla plattformar.

// Repository i KMP med 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 — UI-ramverk för KMP baserat på Jetpack Compose. Gör det möjligt att skriva gränssnitt i Kotlin för Android, iOS, Desktop och Web. 2025 nådde Compose Multiplatform stabil status för Android och Desktop; iOS-målet är i beta. För produktionsprojekt med inbyggt UI förblir KMP:s fördel den främsta skillnaden från Flutter.