Quand Baptiste et Marek ont créé BAM en 2014, ils ont tout de suite saisi le potentiel du développement cross-platform. Précurseur, puis leader sur la technologie React Native, BAM développe également des projets en code natif pour iOS et Android mais aussi en Flutter.

Bien que les technologies cross-platform actuelles permettent de gagner un temps certain lors du développement d'un projet, elles ne sont pas sans compromis : évolutivité limitée à ce que le framework propose, développement natif encore nécessaire pour certaines fonctionnalités...

KMM serait-il le framework permettant d'y remédier ?

Le développement natif toujours populaire

Même si les avantages des frameworks cross-platform ont séduit bon nombre de développeurs, aujourd'hui l'immense majorité des applications reste développée en code natif.

De plus la plupart des développeurs mobiles sont spécialistes d'une plateforme (iOS ou Android) et ne souhaitent pas forcément migrer vers un framework cross-platform qui impliquerait un changement de langage ou d'IDE.

KMM permet aux développeurs de garder leur environnement de développement natif

C'est l'une des différences fondamentales avec les autres solutions dites cross-platform. La structure d'un projet KMM est très similaire à celle d'un projet spécifique à la plateforme. Ainsi, on peut consommer une bibliothèque écrite en KMM comme n'importe quel autre module ou bibliothèque tierce. De plus, un développeur iOS peut utiliser un module écrit en Kotlin Multiplatform sans même savoir qu'il a été écrit en Kotlin, grâce à l'intégration poussée de KMM avec Swift/Objective-C.

Une migration progressive est possible

Sur un projet natif existant qui peut comporter des dizaines d'écrans, on peut vouloir faire une migration très progressive, au fil de la maintenance de l'application. KMM permet de partager facilement du code quelle que soit son ampleur : de quelques structures de données jusqu'à la logique complète de l'application, couche réseau et persistance incluses.

À titre de comparaison la migration vers un framework cross-platform classique nécessite de migrer des fonctionnalités complètes (UI incluse), et oblige à dupliquer et synchroniser les structures de données existantes.

KMM permet de partager du code sans compromettre l'évolutivité de l'app

C'est l'une des grosses faiblesses des frameworks React Native et Flutter : il faut sans cesse tenir compte des nouvelles versions d'iOS et d'Android. On est donc à la merci d'un retard, d'un bug ou même d'une absence d'intégration d'une nouvelle feature de l'OS.

On retrouve le même problème avec toutes les bibliothèques tierces, lesquelles n'ont pas forcément de binding cross-platform officiel ou officieux de bonne qualité, et qu'on devra donc développer soi-même.

Notons qu'on a potentiellement le même problème pour les bibliothèques en KMM : on ne peut pas partager une bibliothèque même écrite en Kotlin si elle n'a pas été prévue pour fonctionner directement avec KMM.

Cependant, il y a une vraie fluidité entre le code KMM et le code natif (pas de bridge, les objets KMM sont interopérables avec les objets natifs...) ce qui en fait la solution de choix pour les applications qui ont une implémentation de logique à partager, mais qui ont de toute façon des spécificités par plateforme à partager (par exemple : respect strict des guidelines et des Design Systems de chaque OS, intégration multimédia poussée...)

KMM nécessite de ne connaître que 2 langages ?

Les solutions cross-platform permettent d'arriver à une base de code unifiée et dans le même langage dans la plupart des cas.

Cependant, quand le projet se complexifie il n'est pas rare de devoir connaître l'environnement natif (développement d'un bridge, changement de configuration du projet...).

Ce sont alors de nouveaux outils et de nouveaux langages qui ne sont pas forcément maîtrisés par le développeur. On doit finalement avoir une triple connaissance (framework cross-platform + Android + iOS) pour pouvoir intervenir sur l'ensemble du projet.
Sur un projet développé en natif, on a déjà les deux compétences iOS et Android. Plusieurs choix sont alors possibles pour ajouter du KMM : faire développer la brique commune par l'équipe Android, créer une équipe dédiée, former les développeurs iOS pour pouvoir la maintenir...
Quoi qu'il en soit ce ne sont que 2 langages à maîtriser, et de plus ces langages sont assez proches. Notons toutefois que même si c'est le même langage, développer en Kotlin pour Android ou pour Kotlin Multiplatform peut être assez différent et nécessite une montée en compétence non négligeable.

Mais alors, quels sont les compromis ?

KMM est une technologie encore jeune, l'utiliser n'est pas sans contrepartie :

• L'écosystème n'a pas la maturité de ceux des solutions natives ou même de React Native, on risque donc de ne pas trouver de bibliothèque existante ou suffisamment mature pour certains cas d'usage.
• Bien que l'interopérabilité Kotlin-Swift fonctionne bien dans la plupart des cas, il reste des cas (asynchronisme, enum...) où il faudra retravailler le code "à la main" pour générer des API Swift vraiment idiomatiques.
• Le modèle mémoire de Kotlin Native très strict et controversé a pu rebuter plus d'un développeur qui essayait KMM. Bonne nouvelle, un nouveau modèle est prévu et est même disponible à titre expérimental dans Kotlin 1.6.
•  

Ces quelques points durs ne sont clairement pas rédhibitoires, mais réservent cependant l'usage de Kotlin Multiplatform aux équipes assez matures pour les comprendre et les contourner.

KMM est supporté par Jetbrains

Kotlin a su garder une des grandes forces de Java : il convient parfaitement au monde de l'entreprise. Une roadmap publique, mais surtout une évolution maitrisée rassurent les responsables techniques. Cette même recette appliquée à KMM en fait une solution solide et pérenne pour les années à venir.

Les développeurs ?? Kotlin

Les développeurs natifs sont en général très satisfaits de leur environnement et de leur langage : Google et Apple investissent énormément pour offrir l'expérience de développement la plus fluide et intégrée possible.

Bien souvent les développeurs mobiles n'envisagent pas de basculer sur un framework cross-platform qui peut sembler un cran en dessous en termes de Developer Experience.

En revanche, Kotlin Multiplatform semble bénéficier d'une certaine traction auprès des développeurs natifs. Sans que cela soit le critère principal du choix technologique de votre produit, cela pourrait bien être un élément qui permette de garder ou d'attirer les meilleurs développeurs...

Un ecosystème qui a du potentiel

Kotlin Multiplatform, c'est aussi la possibilité de partager du code avec une appli Web ou bien encore un serveur JVM ou Node.js. De plus en plus de bibliothèques Kotlin sont écrites ou portées vers KMP et permettent de développer les couches de données et de logique de l'application en s'abstrayant complètement de la plateforme.
Côté UI, Jetbrains propose déjà des versions de Compose (le nouveau framework UI d'Android) pour le desktop (et même pour le web sous certaines conditions). Il est très probable qu'une version iOS arrive très prochainement puisque techniquement rien ne s'y oppose.

On aura alors une solution complète permettant de partager toute la logique de l'application et tout ou partie de l'UI !