Blog
Kotlin Multiplatform : partager sa logique métier entre Android et iOS
8 min de lecture
KMP permet de mutualiser la logique métier entre Android et iOS sans sacrifier le rendu natif de chaque plateforme. Voici comment ça fonctionne en pratique.
Kotlin Multiplatform (KMP) est l'une des évolutions les plus importantes du développement mobile de ces dernières années. Contrairement à Flutter qui remplace le rendu natif par son propre moteur, KMP adopte une approche radicalement différente : partager uniquement la logique métier, et laisser chaque plateforme gérer son propre UI avec ses propres outils natifs.
C'est un changement de perspective important. Et dans certains contextes, c'est exactement la bonne approche.
Ce que KMP change vraiment
Pendant longtemps, les équipes mobiles avaient deux options : développer deux applications séparées, ou utiliser un framework cross-platform comme Flutter ou React Native pour partager aussi l'UI.
KMP propose un troisième chemin : écrire une fois la logique métier en Kotlin (les modèles de données, les repositories, les use cases, la couche réseau, le cache), et l'utiliser telle quelle dans l'app Android en Jetpack Compose et dans l'app iOS en SwiftUI.
Concrètement, une règle de calcul, un algorithme de synchronisation, ou un modèle de domaine n'a besoin d'être écrit qu'une seule fois. Les bugs corrigés dans la logique commune le sont pour les deux plateformes simultanément. Les features qui reposent sur la logique partagée sont livrées deux fois plus vite.
L'architecture d'un projet KMP
Un projet KMP typique se structure autour d'un module shared qui contient les éléments communs.
Dans ce module partagé, on trouve généralement : les modèles de données (data classes Kotlin), les interfaces de repository, les implémentations réseau (avec Ktor, le client HTTP multiplateforme), la couche de cache (SQLDelight pour une base de données multiplateforme), les use cases et la logique de domaine.
Les modules platform-specific (androidApp et iosApp) contiennent l'UI et les implémentations natives nécessaires. Côté iOS, KMP génère un framework Swift que Xcode consomme naturellement.
Cette séparation nette favorise une architecture propre : la logique n'est jamais couplée à l'UI, les tests unitaires s'écrivent une seule fois pour le module commun, et chaque plateforme peut faire évoluer son interface indépendamment.
KMP vs Flutter : deux philosophies différentes
La confusion entre KMP et Flutter est fréquente, mais les deux répondent à des besoins différents.
Flutter remplace l'UI native par son propre moteur de rendu. Avantage : cohérence visuelle parfaite entre plateformes, une seule codebase complète. Inconvénient : l'app ne « ressemble » pas exactement à une app native, les widgets système sont émulés.
KMP conserve l'UI native de chaque plateforme. Avantage : l'app Android respecte les conventions Material, l'app iOS respecte les guidelines Apple, les composants système sont natifs. Inconvénient : il faut maintenir deux couches UI.
En pratique, KMP est particulièrement adapté aux entreprises qui ont déjà deux équipes mobiles, qui veulent garder une UI vraiment native, et qui souhaitent réduire la duplication de logique sans tout refaire. Flutter est plus adapté aux startups qui partent de zéro avec une équipe unique.
KMP en production : cas concret
Sur des projets de Field Service Management avec une logique métier dense synchronisation offline des interventions, calcul des temps d'arrêt, gestion des états machines, règles de planification KMP est particulièrement bien adapté.
Cette logique, écrite une seule fois en Kotlin dans le module partagé, fonctionne de façon identique sur Android et iOS. Les techniciens utilisent l'app Android (interface Material native), les responsables utilisent iOS pour le dashboard. Les deux bénéficient exactement des mêmes règles métier, sans risque de divergence.
La couche réseau utilise Ktor, le cache local SQLDelight, et les use cases sont testés unitairement une seule fois. Le gain en maintenabilité est significatif dès que la logique dépasse une certaine complexité.
Pour conclure
KMP n'est pas une silver bullet, et ce n'est pas non plus un concurrent direct de Flutter. C'est un outil complémentaire, adapté aux contextes où le natif est important et où la logique métier est suffisamment dense pour justifier le partage. Si vous avez une app avec des règles métier complexes et que vous ciblez Android ET iOS avec des équipes séparées, KMP mérite sérieusement d'être évalué.
Discuter d'un projet
Un projet Flutter, FlutterFlow ou KMP en tête ?
Un call de 20 minutes pour cadrer votre besoin et vous proposer un plan d'action concret.