Kotlin Multiplatform en 2026 : partager son code Android, iOS et web

Pourquoi Kotlin Multiplatform s’impose en 2026

Le développement multiplateforme n’est pas un concept nouveau. Depuis les débuts de PhoneGap en 2009, l’industrie cherche le Graal : écrire une seule fois, déployer partout. En 2026, Kotlin Multiplatform (KMP) a franchi un cap décisif. Après des années de bêta, la technologie portée par JetBrains est désormais stable, adoptée par des géants comme Netflix, McDonald’s, VMware et Philips, et soutenue par Google qui l’a officiellement intégrée dans son écosystème Android.

Selon les chiffres de la dernière enquête JetBrains Developer Ecosystem Survey (2025), 29 % des développeurs Kotlin utilisent désormais KMP en production, contre seulement 12 % en 2023. La croissance est nette, portée par une promesse simple : mutualiser la logique métier entre Android, iOS et le web sans renoncer à la qualité native.

Mais concrètement, comment ça fonctionne ? Quels sont les gains réels ? Et surtout, dans quels cas l’adopter ?

Comment fonctionne Kotlin Multiplatform

Le principe : du code partagé, des cibles multiples

Kotlin Multiplatform repose sur le compilateur Kotlin, capable de produire du bytecode JVM (pour Android et le serveur), du code natif via LLVM (pour iOS, macOS, Linux, Windows) et du JavaScript ou du WebAssembly (pour le navigateur).

Le développeur structure son projet en trois types de modules :

• commonMain : le code partagé entre toutes les plateformes (modèles, logique métier, appels réseau, gestion d’état).
• androidMain, iosMain, jsMain ou wasmJsMain : le code spécifique à chaque cible.
• Des interfaces expect/actual : un mécanisme élégant qui permet de déclarer une API dans le code commun et de fournir une implémentation propre à chaque plateforme.

Voici un exemple concret :

// commonMain — Déclaration
expect fun getPlatformName(): String

// androidMain — Implémentation Android
actual fun getPlatformName(): String = "Android ${Build.VERSION.RELEASE}"

// iosMain — Implémentation iOS
actual fun getPlatformName(): String = UIDevice.currentDevice.systemName() +
    " " + UIDevice.currentDevice.systemVersion

// wasmJsMain — Implémentation Web
actual fun getPlatformName(): String = "Web (Wasm)"

Ce mécanisme est bien plus puissant qu’un simple #ifdef : il est vérifié à la compilation, ce qui élimine toute une catégorie de bugs liés aux divergences entre plateformes.

L’écosystème de bibliothèques en 2026

L’un des freins historiques de KMP était le manque de bibliothèques multiplatformes. Ce n’est plus le cas. En 2026, l’écosystème est riche et mature :

Domaine	Bibliothèque KMP	Statut 2026
Réseau HTTP	Ktor Client	Stable (3.x)
Sérialisation JSON	kotlinx.serialization	Stable
Base de données locale	SQLDelight	Stable (2.x)
Injection de dépendances	Koin Multiplatform	Stable
Navigation	Voyager / Decompose	Stable
UI partagée	Compose Multiplatform	Stable (Android, iOS, Desktop, Web)
Gestion d’état	MVI Kotlin / KMP-ViewModel	Stable
Tests	kotlin.test + Turbine	Stable
Date et heure	kotlinx-datetime	Stable
Coroutines	kotlinx.coroutines	Stable

Cette maturité change la donne. Il est désormais possible de construire une application complète — de la couche réseau à la persistance locale — en code 100 % partagé.

Compose Multiplatform : partager aussi l’UI

De la logique à l’interface

La grande nouveauté de ces deux dernières années, c’est Compose Multiplatform. Développé par JetBrains sur la base de Jetpack Compose (le framework UI déclaratif de Google pour Android), il permet désormais de partager non seulement la logique, mais aussi l’interface utilisateur entre Android, iOS, desktop et web.

Concrètement, un même composable Kotlin peut s’afficher sur un téléphone Android, un iPhone, un navigateur web et une application de bureau :

@Composable
fun UserProfileScreen(viewModel: UserProfileViewModel) {
    val state by viewModel.state.collectAsState()

    Column(
        modifier = Modifier
            .fillMaxSize()
            .padding(16.dp)
    ) {
        AsyncImage(
            model = state.avatarUrl,
            contentDescription = "Photo de profil",
            modifier = Modifier.size(120.dp).clip(CircleShape)
        )
        Spacer(Modifier.height(12.dp))
        Text(
            text = state.displayName,
            style = MaterialTheme.typography.headlineMedium
        )
        Text(
            text = state.email,
            style = MaterialTheme.typography.bodyLarge,
            color = MaterialTheme.colorScheme.onSurfaceVariant
        )
    }
}

Ce code fonctionne tel quel sur les quatre plateformes. Les rendus sont natifs : sur iOS, Compose Multiplatform utilise un canvas Skia/Skiko intégré dans une UIViewController, ce qui garantit des performances de 60 fps et un accès complet aux API système.

Faut-il partager l’UI ou la garder native ?

C’est la question stratégique. Chez Lueur Externe, agence web et mobile basée dans les Alpes-Maritimes, nous accompagnons nos clients sur ce choix selon leur contexte :

• UI partagée avec Compose Multiplatform : idéale pour les applications métier (B2B, back-office, outils internes), les MVP et les projets à budget contraint. Le gain de productivité est considérable : 40 à 60 % de réduction du temps de développement UI selon notre expérience terrain.
• UI native + logique partagée : recommandée pour les applications grand public exigeant un rendu pixel-perfect conforme aux guidelines Material 3 (Android) et Human Interface Guidelines (iOS). Les marques premium ou les apps à forte composante UX y trouvent leur compte.

La bonne nouvelle, c’est que KMP n’impose pas un choix binaire. On peut mixer les deux approches au sein du même projet : partager 90 % des écrans via Compose Multiplatform et garder des écrans natifs pour les interactions les plus spécifiques (caméra AR, widgets système, etc.).

KMP vs Flutter vs React Native : comparatif 2026

Le marché du développement multiplateforme compte trois acteurs majeurs en 2026. Voici un comparatif factuel :

Critère	Kotlin Multiplatform	Flutter	React Native
Langage	Kotlin	Dart	JavaScript / TypeScript
Approche	Logique partagée + UI optionnelle	UI + logique partagées	UI + logique partagées
Rendu UI	Natif ou Compose (Skia)	Propre moteur (Impeller)	Composants natifs via bridge
Performances	Natives (compilation AOT)	Quasi-natives	Variables (nouveau arch. 2024+)
Taille d’APK minimal	~3-5 Mo	~8-12 Mo	~7-10 Mo
Accès aux API natives	Direct (expect/actual, cinterop)	Via platform channels	Via modules natifs / Turbo Modules
Support web	Kotlin/Wasm + Compose for Web	Flutter Web (Wasm)	React DOM (naturel)
Communauté (GitHub stars)	~16k (kotlin-multiplatform)	~167k	~120k
Maturité entreprise	Netflix, McDonald’s, Philips	BMW, eBay, Google Pay	Meta, Shopify, Discord

Les forces distinctives de KMP

• Pas de réécriture nécessaire : une application Android existante en Kotlin peut adopter KMP de manière incrémentale, module par module. C’est un avantage considérable par rapport à Flutter qui impose une réécriture en Dart.
• Interopérabilité native parfaite : sur iOS, KMP produit un framework natif directement consommable en Swift. Pas de bridge, pas de sérialisation JSON inter-processus.
• Un seul langage pour le backend et le mobile : avec Ktor côté serveur, une équipe full-stack peut travailler en Kotlin de bout en bout.
• WebAssembly : la cible Kotlin/Wasm, stabilisée en 2025, offre des performances web proches du natif, bien supérieures au JavaScript transpilé.

Les limites à connaître

• Courbe d’apprentissage iOS : les développeurs Swift doivent s’adapter à l’écosystème Gradle et aux idiomes Kotlin. L’intégration dans Xcode, bien qu’améliorée avec le plugin SKIE d’Touchlab et le support Fleet, reste moins fluide que le développement Swift natif.
• Taille de la communauté : même si elle croît rapidement, la communauté KMP est encore plus petite que celles de Flutter et React Native. Trouver des développeurs KMP seniors peut être un défi.
• Compose Multiplatform sur iOS : bien que stable, certaines bibliothèques UI tierces (composants très spécifiques) n’ont pas encore d’équivalent multiplateforme.

Cas d’usage concrets : quand choisir KMP ?

1. Application mobile avec logique métier complexe

Une fintech, une healthtech ou une application SaaS avec des règles métier sophistiquées (calculs financiers, validations, algorithmes) tire un bénéfice immédiat de KMP : la logique est écrite, testée et maintenue une seule fois. Les bugs de parité entre plateformes — cauchemar classique du développement natif parallèle — disparaissent.

2. Migration progressive d’une app Android existante

C’est l’un des scénarios les plus fréquents. Une entreprise disposant d’une app Android mature en Kotlin souhaite lancer une version iOS. Plutôt que de tout réécrire en Swift, elle extrait sa couche métier dans un module KMP. L’équipe Android continue de travailler normalement ; l’équipe iOS consomme le module partagé comme un framework natif.

3. Application web + mobile avec un backend Kotlin

Les organisations qui utilisent déjà Kotlin côté serveur (Spring Boot, Ktor) ont un avantage stratégique : elles peuvent partager des DTOs, des validateurs et des utilitaires entre le backend, le frontend web (Kotlin/Wasm) et les apps mobiles. Un seul langage, une seule source de vérité.

4. SDK ou bibliothèque distribuée à des tiers

Plusieurs entreprises utilisent KMP pour publier un SDK disponible simultanément sur Android (package Maven), iOS (CocoaPods / Swift Package Manager) et web (npm). C’est le cas de Touchlab, Apollo GraphQL (client Kotlin) et de nombreuses startups.

Bonnes pratiques pour démarrer un projet KMP en 2026

Fort de plus de 20 ans d’expérience dans le développement web et mobile, l’équipe de Lueur Externe a identifié plusieurs bonnes pratiques issues de projets réels :

Architecture recommandée

• Clean Architecture en modules Gradle : séparez clairement shared:domain, shared:data, shared:presentation et les modules spécifiques à chaque plateforme.
• Injection de dépendances avec Koin : sa version multiplateforme est la plus mature et la plus simple à configurer.
• Gestion d’état avec des StateFlows : les StateFlow Kotlin sont interopérables avec SwiftUI (@ObservableObject) et Compose sans couche d’adaptation.

Outillage

• IDE : Android Studio (Ladybug+) ou JetBrains Fleet pour une expérience véritablement multiplateforme. Xcode reste nécessaire pour la compilation iOS finale.
• CI/CD : GitHub Actions avec des runners macOS pour les builds iOS. Le plugin Gradle KMP supporte nativement les caches de compilation.
• Tests : kotlin.test pour les tests unitaires partagés, Turbine pour tester les Flows, et des tests d’UI par plateforme (Espresso, XCUITest ou Compose UI Test).

Pièges à éviter

• Ne pas tenter de tout partager dès le départ : commencez par la couche réseau et les modèles de données, puis étendez progressivement.
• Ne pas ignorer les spécificités mémoire d’iOS : même si le nouveau gestionnaire de mémoire Kotlin/Native (depuis Kotlin 1.7.20) a résolu la plupart des problèmes de concurrence, il faut rester attentif aux cycles de rétention lorsque KMP interagit avec des objets Swift.
• Documenter les interfaces expect/actual : ces contrats constituent la frontière entre le partagé et le natif. Une documentation claire évite les incompréhensions entre équipes.

Performances : les chiffres qui comptent

Un sujet récurrent est la performance de KMP, en particulier sur iOS. Voici des benchmarks issus de tests réalisés sur un iPhone 15 Pro (A17 Pro) avec Kotlin 2.1 :

• Démarrage à froid : une app KMP avec Compose Multiplatform démarre en 380 ms en moyenne, contre 320 ms pour une app SwiftUI équivalente. L’écart est négligeable pour l’utilisateur.
• Consommation mémoire : +8 à 12 % par rapport à une app Swift native. Acceptable pour la grande majorité des cas d’usage.
• Taille du binaire : le runtime Kotlin/Native ajoute environ 3 à 5 Mo au binaire iOS. Avec les optimisations du compilateur K2, c’est 30 % de moins qu’en 2023.
• Performance de calcul pur : sur des algorithmes intensifs (tri, crypto, parsing JSON), Kotlin/Native atteint 85 à 95 % des performances de Swift grâce aux optimisations LLVM.

Ces chiffres confirment que KMP n’est plus un compromis de performance en 2026. Pour la majorité des applications métier et grand public, la différence avec le natif pur est imperceptible.

L’avenir : ce qui arrive en 2026-2027

L’écosystème KMP continue d’évoluer à un rythme soutenu :

• Kotlin 2.2 (prévu T3 2026) apportera des améliorations significatives du temps de compilation pour les cibles iOS.
• Compose Multiplatform 1.8+ intègre le support natif des widgets iOS (UIKit interop amélioré), des animations Lottie et du rendu adaptatif selon la plateforme.
• Kotlin/Wasm Component Model permettra une interopérabilité transparente avec les Web Components standards.
• Ambrosia (nom de code) : JetBrains travaille sur un outil de migration automatisé Swift → Kotlin pour accélérer l’adoption côté iOS.
• Support Gradle amélioré : le nouveau plugin kotlin-multiplatform simplifie drastiquement la configuration des projets, réduisant le boilerplate Gradle de près de 50 %.

Conclusion : KMP, le choix pragmatique pour 2026

Kotlin Multiplatform a quitté le territoire de l’expérimentation pour devenir un choix de production crédible et performant. Sa philosophie — partager ce qui doit l’être, rester natif là où ça compte — répond à un besoin réel des équipes de développement qui refusent le compromis entre productivité et qualité.

Que vous souhaitiez lancer une nouvelle application multiplateforme, étendre une app Android existante vers iOS, ou mutualiser la logique entre votre web app et vos apps mobiles, KMP offre une voie pragmatique et incrémentale.

Chez Lueur Externe, nous accompagnons les entreprises dans l’adoption de Kotlin Multiplatform, du cadrage technique initial au déploiement en production. Notre expertise certifiée sur les écosystèmes Android, iOS et web nous permet de concevoir des architectures KMP robustes, adaptées à votre contexte métier et à vos contraintes techniques.

Prêt à explorer Kotlin Multiplatform pour votre projet ? Contactez notre équipe pour un audit gratuit de faisabilité et une estimation de gains.