Kotlin Multiplatform : qu'est-ce que c'est, shared module et expect/actual

Qu'est-ce que Kotlin Multiplatform ?

Kotlin Multiplatform est une technologie de compilation croisée qui permet d'écrire du code partagé en Kotlin et de le compiler pour différentes plateformes : JVM (Android), LLVM (iOS, macOS, watchOS), JavaScript (Web) et binaires natifs (Linux, Windows). KMP n'est pas un framework d'UI — il résout le problème de réutilisation de la logique métier, pas des interfaces.

L'architecture KMP est construite autour d'un shared module — un module Gradle contenant commonMain avec du code indépendant de la plateforme et des source sets pour chaque cible (androidMain, iosMain, desktopMain). Selon les données JetBrains pour 2025, plus de 40% des nouveaux projets Kotlin utilisent KMP pour partager du code entre plateformes.

Kotlin Multiplatform Mobile (KMM) — l'ancien nom pour le scénario mobile iOS+Android. Depuis Kotlin 2.1+, le terme KMM a été remplacé par Kotlin Multiplatform, car la technologie a dépassé le développement mobile. Netflix, McDonald's et VMware utilisent KMP en production pour partager du code entre applications mobiles.

Mécanisme expect/actual : architecture

Expect/actual — le mécanisme clé de KMP pour travailler avec du code spécifique à une plateforme. Dans commonMain, une déclaration expect (fonction, classe, propriété) est déclarée, et dans chaque source set spécifique à une plateforme (androidMain, iosMain), une implémentation actual est fournie. Le compilateur vérifie que pour chaque expect, il existe un actual sur chaque plateforme cible.

// commonMain — déclaration d'API de plateforme
expect fun getPlatformName(): String

expect class PlatformContext(val appVersion: String)

// androidMain — actual pour Android
actual fun getPlatformName(): String = "Android \${Build.VERSION.SDK_INT}"

// iosMain — actual pour iOS
actual fun getPlatformName(): String =
    UIDevice.currentDevice.systemName

La hiérarchie des source sets dans KMP permet de créer des niveaux intermédiaires : par exemple, iosArm64Main (périphériques iOS physiques) et iosSimulatorArm64Main (simulateur) avec iosMain partagé. Le code de commonMain est disponible pour toutes les plateformes, tandis que le code de iosMain est disponible uniquement pour les cibles iOS. Cela réduit la duplication lorsque l'implémentation diffère non pas pour chaque plateforme mais pour un groupe de plateformes.

En pratique, expect/actual est utilisé pour : accéder au stockage local (SharedPreferences vs NSUserDefaults), réseau (HttpEngine par plateforme), accès au système de fichiers, cryptographie et analytique. JetBrains recommande de minimiser le nombre de déclarations expect/actual et de déplacer autant de code que possible vers commonMain.

Shared module : structure et Gradle

Shared module — un module Gradle standard avec le plugin org.jetbrains.kotlin.multiplatform. Il contient du code partagé dans src/commonMain/kotlin/ et des implémentations spécifiques à la plateforme dans src/androidMain/kotlin/ et src/iosMain/kotlin/. Un projet KMP inclut également androidApp et iosApp, qui dépendent du 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")
            }
        }
    }
}

La configuration Gradle pour KMP nécessite la déclaration explicite des cibles iOS — x64 (simulateur Intel), arm64 (périphériques physiques) et simulatorArm64 (simulateur Apple Silicon). Un framework Apple séparé est généré pour chaque cible. Le plugin kotlin("multiplatform") configure automatiquement la compilation pour JVM et LLVM en fonction des cibles déclarées.

Ktor et kotlinx.serialization — des bibliothèques KMP standard qui prennent en charge le code partagé. Ktor fournit un client HTTP avec des moteurs pour chaque plateforme (OkHttp pour Android, Darwin pour iOS). kotlinx.serialization fonctionne sur toutes les plateformes sans expect/actual grâce à son implémentation multiplateforme dans commonMain.

Intégration iOS via Kotlin/Native

Kotlin/Native — un compilateur Kotlin pour le code natif via LLVM. Pour iOS, le shared module est compilé en un framework Apple (.framework) qui est connecté via Xcode. L'appel au code partagé depuis Swift/Objective-C se fait via les en-têtes Objective-C générés, donc l'API du shared module doit être compatible avec Objective-C.

Limitations de l'intégration iOS : les collections Kotlin (List, Map) sont converties en NSArray/NSDictionary. Les fonctions avec paramètres par défaut ne sont pas exportées — des surcharges sont nécessaires. Pour les fonctions suspend, des méthodes basées sur des callbacks sont générées avec @ObjCName et la prise en charge async/await à partir de Kotlin 2.0+.

// Application iOS : appel du shared module depuis 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)")
            }
        })
    }
}

L'intégration du shared module dans Xcode se fait via embed-and-framework — le .xcframework généré est ajouté au projet Xcode. Le plugin Gradle peut automatiquement mettre à jour le framework lors de la compilation via embedAndSignAppleFrameworkForXcode. Pour tester sur le simulateur, un binaire iosSimulatorArm64 ou iosX64 est suffisant.

KMP vs Flutter vs React Native

Le choix entre KMP, Flutter et React Native dépend de la priorité : réutilisation du code ou multiplateforme complète. KMP fournit une UI native sur chaque plateforme mais nécessite deux bases de code pour l'interface. Flutter et React Native utilisent une UI unique mais sacrifient la nativeité.

Quand choisir KMP : le projet nécessite une UI haute performance (jeux, cartes, animations), du code natif existant doit être réutilisé, l'équipe connaît déjà Kotlin et les plateformes natives. Quand choisir Flutter/RN : MVP ou startup avec un budget limité, équipe mono-profil, l'UI ne nécessite pas de personnalisation native profonde.

Outils et bibliothèques KMP

L'écosystème d'outils KMP comprend des bibliothèques pour toutes les couches de l'application : réseau (Ktor), sérialisation (kotlinx.serialization), base de données (SQLDelight), navigation (Decompose), DI (Koin) et stockage de données (multiplatform-settings). JetBrains prend en charge Compose Multiplatform — un framework d'UI en Kotlin fonctionnant sur toutes les plateformes.

// Référentiel KMP avec 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 — un framework d'UI pour KMP basé sur Jetpack Compose. Il permet d'écrire des interfaces en Kotlin pour Android, iOS, Desktop et Web. En 2025, Compose Multiplatform a atteint le statut stable pour Android et Desktop ; la cible iOS est en version bêta. Pour les projets de production avec UI native, l'avantage de KMP reste la principale différence par rapport à Flutter.