🔧 Kotlin Multiplatform en production : ce que ça change vraiment

Sur un projet mobile récent, j’ai fait un choix assez clair : plutôt que de maintenir deux codebases natives, partir sur Kotlin Multiplatform + Compose Multiplatform. L’application est une plateforme de transactions sécurisées entre acheteurs et vendeurs, destinée à un marché arabophone. Au final : 52+ routes de navigation 30+ ViewModels 3 langues : FR / EN / AR Android (API 26+) et iOS 16+ Kotlin 2.0 Et surtout, une grande partie du code vit dans commonMain. 📱 Ce que ça change au quotidien La logique métier n’est plus dupliquée entre Android et iOS. Par exemple, tout le cycle d’une transaction — génération du code, paiement, livraison, gestion d’un éventuel litige — est développé une seule fois. Cela évite une bonne partie des problèmes du type : « ça fonctionne sur Android, mais pas sur iOS ». Côté architecture, nous sommes partis sur MVVM + StateFlow, avec un UiState immutable exposé par chaque ViewModel. L’état est ainsi centralisé, observable et facilement testable. 🌍 Et pour le multilingue ? FR, EN et AR sont gérés directement dans le code partagé, avec le support du RTL. Avec moko-resources, les ressources sont typées et générées à la compilation, tout en restant accessibles depuis les deux plateformes. ⚠️ Le vrai piège de KMP Ce n’est pas forcément la technologie. C’est de vouloir tout partager à tout prix. Dans ce projet, les quelques implémentations spécifiques aux plateformes concernent principalement : les notifications push ; la gestion des permissions ; certaines parties du réseau selon la plateforme. Pour le reste — UI Compose, ViewModels, appels API avec Ktor/Ktorfit, sérialisation, navigation — le code est partagé dans commonMain. Et honnêtement, c’est là que KMP prend tout son sens. 🛠️ Une difficulté que je n’avais pas anticipée Le build iOS en CI/CD était assez lent. Après optimisation de la configuration Kotlin/Native et la désactivation de certaines phases d’analyse, notamment autour de la dévirtualisation et de l’escape analysis, nous avons obtenu une amélioration sensible des temps de build. Comme souvent, il s’agit d’un compromis : gagner du temps côté build au prix de quelques optimisations runtime. Au final, mon retour sur KMP est plutôt positif. Mais je pense que sa vraie valeur n’est pas simplement de dire « un seul code pour deux plateformes ». C’est surtout de pouvoir partager la logique métier et l’architecture, tout en gardant la liberté de laisser aux plateformes ce qui doit réellement leur appartenir. Vous avez déjà mis KMP en production ? Quel a été votre plus gros point de friction ?