Kotlin Multiplatform Mobile pour le développement d'application

Le développement hybride privilégie la réduction des coûts en évitant la duplication du code, mais présente de nombreux désavantages. Si vous n'êtes pas familiers avec ces concepts, nous vous invitons à lire cet article en préambule. Et s'il était possible de limiter cette duplication tout en s'épargnant des désavantages rencontrés ? C'est en tout cas la promesse de cette technologie qui a récemment vu le jour : Kotlin Multiplatform Mobile. Tour d'horizon.

Kotlin Multiplatform Mobile : Qui est ce nouveau venu ?

Kotlin Multiplatform Mobile (KMM) est un framework de développement multiplateforme créé par JetBrains. Cette entreprise est d’ailleurs à l’origine de Kotlin, un langage de programmation populaire pour Android et officiellement supporté depuis 2017. Son objectif est de permettre aux développeurs de partager du code entre iOS et Android.

KMM est d'ailleurs issu d'une volonté globale de JetBrains de populariser l'utilisation de son langage sur d'autres plateformes (JS, Linux, Windows). Appelée Kotlin Multiplatform (KMP), cette technologie repose sur de la cross-compilation, permettant de compiler du code Kotlin en un code natif sur la plateforme ciblée (Kotlin/JVM, Kotlin/JS ou Kotlin/Native en fonction de la plateforme). KMP permet donc de s'affranchir de la machine virtuelle Java (JVM), dans laquelle s'exécute habituellement le code Kotlin, et qui n'est pas omniprésente.

Ainsi, si on reprend le cas de KMM, il s'agit de pouvoir exécuter du code Kotlin aussi bien sur Android que sur iOS. En suivant la documentation, on se retrouve donc avec un projet contenant une application iOS, une application Android et un framework écrit en Kotlin qui peut être utilisé dans les deux applications.

C'est fiable KMM comme techno ?

À l'écriture de cet article, KMM est en bêta depuis octobre 2022. Les dénominations alpha & beta sont définies par JetBrains selon leurs propres règles; Bêta signifie pour eux que la technologie est bientôt terminée (en tout cas sa première version) et stable, qu'elle peut être utilisée en production (comme c'est déjà le cas) et que peu de changements sont à prévoir dans les prochaines migrations.

Outre leur bonne communication et documentation, le fait que le développement de KMM soit listé parmi les Key priorities apporte une confiance pour l'intégration de la technologie à de nouveaux projets, sans craindre pour leur avenir.

Fortement impacté par l'invasion russe en Ukraine, JetBrains a su démontrer son sérieux en fermant ses bureaux de développement en Russie et relocalisant ses employés. La bêta de KMM a été retardée de quelques mois, mais les impacts s'arrêtent là.

Et au pire ? Nombre d'outils et de SDK ont vu le jour depuis le début des smartphones, pour se retrouver régulièrement au placard et boudés par la communauté, toujours attirée par l'innovation. Le point positif de KMM est que peu importe le développement de la technologie, on peut s'extraire de ce cadre multiplateforme et garder le code existant pour l'application Android et réécrire, si nécessaire, un code similaire en Swift, langage proche en termes de syntaxe et de modernité.

Avec KMM, on partage tout ?

L'utilisation de KMM, sans être dictée, reste cadrée par sa conception et ses limites. Le code partagé concerne généralement la logique métier (business logic). C'est-à-dire les algorithmes et processus qui gèrent les fonctionnalités de l'application, comme les processus de transaction, les appels réseau, la base de données, et toutes les règles de gestion que l'on peut trouver au sein d'une application.

L'interface est codée nativement dans le langage de la plateforme pour afficher les données renvoyées par le framework KMM contenant le code partagé, à savoir la business logic.

KMM offre une solution pour pouvoir utiliser, directement dans le framework partagé, du code spécifique à chaque plateforme. Via la fonctionnalité expect / actual, on peut dans certains cas utiliser les API des plateformes pour garder le maximum de logique au sein du framework malgré les différences d'implémentation.

Quels sont les avantages de Kotlin Multiplatform Mobile ?

L'interface utilisateur, c'est-à-dire les vues, reste développée dans le langage de la plateforme respective, avec toute la puissance que confèrent les dernières APIs. Le look and feel de l'app n'est en aucun cas impacté par l'utilisation de KMM, le rendu est natif. D’aucuns pourraient arguer que c’est un défaut comparé à d’autres technologies hybrides, car on duplique le code d’interface. Nous pensons au contraire que c’est une force ; l’interface est adaptée à chaque plateforme et son rendu est inégalable.

Le temps de développement est évidemment réduit, car la business logic n’a besoin d’être écrite qu’une seule fois. Le gain est d'autant plus important, une fois l'architecture mise en place, sur le support et les futures évolutions.

L'utilisation d'un framework induit la déclaration d'une API pour interfacer le code partagé et celui de l'UI. La séparation est nette entre ces deux codes et se doit d'être le plus clair possible pour connecter de la meilleure manière deux applications distinctes. Ce qui paraît être une contrainte permet en réalité de proposer un code plus simple et ciblé, avec une architecture en couches.

Le fait que l’architecture décrite force les développeurs à séparer la logique métier et le code d’interface a un autre avantage. Sachant que le code d’interface est difficilement testable, on a la garantie que la logique métier en est dépourvu et qu’elle peut donc être facilement structurée par des tests unitaires.

Quels sont les inconvénients de Kotlin Multiplatform Mobile ?

Malheureusement, le code sur Android tourne dans une JVM, et le développement en Kotlin se base sur l'abondante utilisation des librairies Java existantes. Il faut donc se restreindre à celles conçues pour KMM, qui sont quant à elles peu nombreuses. Mais on trouve rapidement de quoi pouvoir développer tout ce dont on a besoin, comme par exemple ce répertoire GitHub qui en fait une liste non exhaustive.

Il faut aussi plus de temps pour la mise en place d'un projet KMM, notamment à cause de la complexité des fichiers build.gradle.kts et de l'intégration des bonnes dépendances. Outre cela, il n'y a pas réellement d'impact sur le développement Android. C'est sur iOS que l'on ressent réellement la présence de KMM : 2 environnements de développement (Xcode, Android Studio), 2 langages (Swift, Kotlin) et le jonglage constant entre ceux-là. Le temps de compilation ainsi que le débogage sont clairement impactés, notamment lorsqu'on touche au code partagé.

Alors, on y croit ?

Conçu pour gagner du temps de développement sans nuire à la qualité du rendu, KMM semble tenir toutes ses promesses. La technologie convainc par sa facilité d'utilisation une fois la mise en place effectuée, et le gain de temps résultant de l'utilisation du code partagé. Le projet se stabilise, sa communauté grandit, et même s'il faut garder un oeil attentif, il semble bien parti pour durer. Néanmoins, il faut rester conscient que KMM ne s'adapte pas à tout type d'application, et il est important de bien mesurer l'impact de son utilisation.