Kotlin Multiplatform Mobile — ce que c'est, concepts clés et architecture de KMM

Qu'est-ce que Kotlin Multiplatform Mobile ?

Kotlin Multiplatform Mobile (KMM) est une technologie qui permet d'écrire la logique métier partagée d'une application mobile en Kotlin et de l'utiliser sur iOS et Android sans duplication de code. Contrairement à Ionic ou Cordova, KMM ne rend pas l'interface dans un WebView — l'interface utilisateur reste complètement native et est écrite en SwiftUI (iOS) et Jetpack Compose (Android).

KMM a été annoncé par JetBrains en 2019 dans le cadre de la stratégie Kotlin Multiplatform. La principale différence par rapport aux autres solutions multiplateformes est que le framework ne tente pas d'unifier l'interface utilisateur, mais se concentre sur le partage du code réellement identique pour les deux plateformes : requêtes réseau, modèles de données, validation de formulaires, règles métier et opérations de base de données.

Selon l'enquête développeurs JetBrains (2025), KMM est utilisé par 14 % des développeurs mobiles, et ce chiffre croît de 5 % par an. La technologie est choisie par les entreprises ayant des exigences élevées en matière de performances et d'expérience utilisateur native, pour lesquelles les solutions hybrides sont inacceptables.

Architecture de KMM : module partagé et implémentations de plateforme

L'architecture KMM se compose de trois modules : shared (code commun en Kotlin), iosApp (application iOS native en Swift) et androidApp (application Android native en Kotlin). Le module partagé est compilé en JAR pour Android et en framework universel (Apple Framework) pour iOS.

Module partagé : ce qui va dans le code commun

Le module partagé contient toutes les couches indépendantes de la plateforme : la couche réseau avec Ktor Client, les modèles de données avec sérialisation via kotlinx.serialization, les repositories pour la gestion des données, la validation de formulaires et les règles métier (par exemple, calcul du coût de livraison ou vérification des droits d'accès).

Le module partagé utilise le plugin Gradle Multiplatform et contient trois ensembles de sources : commonMain (code commun), androidMain (implémentations spécifiques à Android) et iosMain (implémentations spécifiques à iOS). Le compilateur Kotlin/Native transforme le code commun en bibliothèque native pour iOS, qui est liée au projet Swift via XCFramework.

Modules de plateforme

Module Android — une application Android standard en Kotlin avec Jetpack Compose ou ViewBinding. Le module partagé est connecté comme une dépendance Gradle ordinaire, et toutes les classes de commonMain sont directement accessibles.

Le module iOS est un projet Xcode en Swift ou Objective-C. Le module partagé est connecté via CocoaPods, Swift Package Manager ou XCFramework. Kotlin/Native génère des en-têtes Objective-C pour exporter les types Kotlin, les rendant accessibles depuis Swift.

Le mécanisme expect/actual dans KMM

expect/actual est un mécanisme de Kotlin Multiplatform qui permet de déclarer une API dans le code partagé (déclaration expect) et de fournir son implémentation séparément pour chaque plateforme (déclaration actual). Le compilateur s'assure qu'une déclaration actual existe pour chaque plateforme cible.

Cas d'utilisation typiques d'expect/actual : obtenir l'heure actuelle avec le fuseau horaire, travailler avec SharedPreferences (Android) / UserDefaults (iOS), fonctions cryptographiques et génération d'UUID. Chaque plateforme utilise sa propre API système.

Sans expect/actual, il serait impossible d'avoir un code de logique métier unifié, car les API pour travailler avec le système de fichiers, le réseau et le stockage diffèrent entre iOS et Android au niveau des appels système. Le mécanisme garantit que le développeur n'oublie pas d'implémenter la partie spécifique à la plateforme.

Pour les appels de plateforme tels que l'utilisation de la caméra ou de la biométrie, KMM propose le mécanisme expect/actual combiné à des plugins similaires à Cordova, mais sur Kotlin/Native. JetBrains a également publié la bibliothèque kotlinx-datetime, qui abstrait la gestion des dates et heures.

Exemples de code KMM

Examinons la structure de base d'un projet KMM avec une déclaration de fonction expect pour la génération d'UUID et son implémentation pour iOS et Android.

// commonMain — déclaration commune
expect fun generateUUID(): String

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

// iosMain — implémentation iOS
actual fun generateUUID(): String {
    return platform.Foundation.NSUUID().UUIDString
}

Dans le code partagé, expect fun generateUUID() est déclarée. Android utilise java.util.UUID, tandis qu'iOS utilise NSUUID du framework Foundation. Dans le reste du code du module partagé, cette fonction est appelée indépendamment de la plateforme.

Un exemple de requête réseau utilisant Ktor Client dans le code partagé :

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

Ce code fonctionne sur les deux plateformes sans modification. Ktor Client utilise automatiquement OkHttp sous Android et NSURLSession sous iOS, sans configuration supplémentaire. La sérialisation JSON via kotlinx.serialisation est également multiplateforme.

Comparaison de KMM avec Flutter et React Native

KMM occupe une position unique parmi les technologies multiplateformes, car il ne tente pas de remplacer l'interface native contrairement à Flutter et React Native. KMM est une solution pour partager la logique, pas pour unifier l'interface.

Le principal avantage de KMM est le contrôle total sur l'interface utilisateur. Si une application doit avoir l'apparence et le comportement natifs sur chaque plateforme (par exemple, utiliser la TabBar iOS et la BottomNavigation Android avec des animations de plateforme), KMM est la seule solution multiplateforme qui assure cela sans solutions de contournement.

L'inconvénient est que l'équipe doit maîtriser simultanément Kotlin, Swift, Jetpack Compose et SwiftUI, ce qui complique le recrutement. Flutter et React Native nécessitent la connaissance d'un seul langage et d'un seul framework.

Avantages et défis de l'adoption de KMM

Kotlin Multiplatform Mobile est une technologie puissante, mais son adoption nécessite une approche équilibrée. Examinons les principaux avantages et les défis typiques auxquels les équipes sont confrontées.

Avantages de KMM

Le premier et principal avantage est la réduction de la duplication de code. Selon les études de cas JetBrains (2024), les équipes qui ont adopté KMM réduisent le code dupliqué de 60 à 80 % pour la couche réseau et de 40 à 50 % pour la logique métier dans son ensemble. Cela impacte directement la vitesse de développement et le nombre de bugs.

Le deuxième avantage est la performance au niveau des applications natives. Contrairement aux frameworks hybrides, KMM n'ajoute pas de couches d'abstraction entre l'interface utilisateur et le système. Le code de la logique métier s'exécute aussi rapidement que s'il était écrit en Swift ou Kotlin pour chaque plateforme séparément.

Défis de l'adoption

Le principal défi est la qualification de l'équipe. Les développeurs doivent connaître Kotlin (pour le module partagé), ainsi que Swift et Jetpack Compose (pour l'interface utilisateur). Trouver un spécialiste universel est difficile, donc les équipes sont généralement composées de développeurs Android et iOS qui maintiennent conjointement le module partagé.

Le deuxième défi est l'outillage. KMM nécessite la configuration de Gradle, CocoaPods ou Swift Package Manager, ainsi que l'intégration avec Xcode. Dans les premières étapes d'un projet, les problèmes de configuration de build sont fréquents, surtout lors du travail avec des bibliothèques C.

Le troisième défi est le débogage. Lorsqu'un bug survient à l'intersection de Kotlin/Native et Swift, déterminer sa cause est plus difficile que dans une application monolithique. JetBrains améliore continuellement les outils de débogage, mais en pratique, les équipes consacrent jusqu'à 20 % de leur temps aux tâches d'infrastructure.