Les possibles de Kotlin MultiPlatform

Explorez Kotlin Multiplatform : un moteur technique pour du code Kotlin multi-plateformes.

19/10/2024

Nous tâchons régulièrement sur ce blog de vulgariser notre savoir technique afin de rendre accessible et compréhensible les spécificités du développement mobile. Nos clients s’interrogent souvent sur l’intérêt d’une technologie plutôt qu’une autre. Nous vous invitons aujourd’hui à découvrir Kotlin MultiPlatform, un moyen d’exploiter du code Kotlin sur d’autres plateformes que Android (iOS, web, etc.).

Rapide historique

Avant de détailler le fonctionnement de Kotlin Multiplatform, il est important d’introduire Kotlin, un langage développé depuis 2011 par Jetbrains, éditeur de logiciels reconnu pour ses outils mis à disposition des développeurs : IntelliJ, Android Studio, etc.

Afin de pallier la lourdeur syntaxique et les limitations de la programmation objet de Java (langage avec lequel est historiquement développé leur logiciel), Jetbrains a entrepris le développement de son propre langage : Kotlin.

Kotlin, dont le nom fait également référence à une île, comme Java, se veut :

Interopérable avec Java (les librairies Java fonctionnent dans une app Kotlin, et inversement),
A la fois orienté objet et fonctionnel,
Garant des mêmes performances que Java.

Pour cela, le code source Kotlin est compilé en un binaire interprétable par la même machine virtuelle que celle utilisée par Java.

La première version stable de Kotlin est proposée en 2016 et son engouement par la communauté est tel, qu’il est officiellement reconnu par Google comme langage supporté sur Android depuis 2017. Depuis, Android est devenu kotlin-first, c’est-à-dire que les nouveautés apportées par Google pour Android sont développées en Kotlin.

Jetbrains réussit encore une fois son pari, en mettant cette fois-ci à disposition un langage, largement plébiscité par la communauté, et décide aujourd’hui d’en élargir le champ des possibles.

"Multiplatform" : un nouveau langage hybride ?

Il convient dès maintenant de faire cette distinction : même si Kotlin Multiplatform tend à répondre aux mêmes problématiques que les différents langages hybrides qui se sont succédés ces dernières années (Cordova, Xamarin, ReactNative, …), l’approche est fondamentalement différente.

Un framework hybride vise à mutualiser l’intégralité du code et adapter les spécificités de chaque plateforme au cas par cas ; Kotlin Multiplatform propose de développer chaque plateforme dans son langage natif et de ne mutualiser que ce qui est générique entre elles.

Pour cela, Kotlin Multiplatform reprend le principe de Kotlin de compiler ce langage en un binaire interprétable par la plateforme cible : un fichier .jar interprété par une JVM (ART, précédemment Dalvik) sur Android et un fichier .framework pour iOS, mais aussi du Javascript pour du web, et bien d’autres

À la sortie, les frameworks hybrides produisent donc une même application pour toutes les plateformes, là où Kotlin Multiplatform produit une application dédiée à chaque plateforme.

Les limites du tout-mutualisé

Chaque plateforme possède ses propres spécificités et contraintes, à la fois techniques mais également dans l’expérience utilisateur : des petites variations design, dans la navigation, dans les gestuelles, dans les menus etc., tant de détails qui influent sur le ressenti d’un utilisateur qui, pour une très grande majorité, n’est coutumier que d’une seule plateforme. Proposer une expérience Android à un utilisateur iOS, c’est le priver de certains de ses repères et risquer de l’amener vers un sentiment que quelque chose ne fonctionne pas correctement, ou du moins pas comme d’habitude.

C’est là tout le défi du tout-mutualisé : trouver un juste équilibre qui convienne tant que possible à tous les utilisateurs, au risque de mixer un méli-mélo de chaque plateforme qui ne convienne finalement à personne ; ou prendre le parti d’une plateforme, au détriment d’une autre.

Techniquement le défi est encore plus grand, puisque certains aspects d’une application mobile ne fonctionnent fondamentalement pas de la même manière (cycle de vie des vues, process en tâche de fond, connexion Bluetooth, …). Les frameworks hybrides doivent donc tordre le fonctionnement nativement prévu par les plateformes pour amener celles-ci à un terrain d’entente, ce qui implique nécessairement une dégradation des performances et de l’expérience utilisateur, en plus de poser des soucis de maintenance et de rétro-compatibilité lorsque les OS évoluent.

Vers une mutualisation maîtrisée

L’approche de Kotlin Multiplatform consiste donc à développer nativement, pour chaque plateforme, tout ce qui est propre à chaque plateforme :

Les vues et la navigation ;
Les aspects techniques fondamentalement différents d’une plateforme à une autre.

Le reste peut ensuite n’être développé qu’une seule fois pour toutes les plateformes :

Ce qui est mutualisable sans impact vis-à-vis de la plateforme. On pensera en premier lieu à la logique métier, qui est totalement indépendante du support ;
Ce qui dispose d’un fonctionnement générique identique et dont le détail de l’implémentation peut être déporté côté natif. On pensera par exemple aux appels réseau.

La part de code commun est donc nettement moindre si on la compare aux frameworks hybrides, où les vues et la navigation sont généralement mutualisées.

L’avantage réside donc plus dans le rendu final – tant du point de vue des performances que de l’expérience utilisateur –, qui est strictement identique à une application native, mais aussi dans la maintenance de l’application qui est fortement simplifiée avec Kotlin Multiplatform – notamment sur les aspects spécifiques à chaque plateforme.

On comprend maintenant l’effervescence autour de Kotlin Multiplatform Mobile et son adoption par des applications mobiles à forte volumétrie. Pour en citer quelques-unes ayant franchi le pas : Autodesk, Coyote, ou plus récemment Netflix !

Vous avez un projet d’application mobile et vous demandez quelle technologie choisir ? Contactez-nous !