Partager la logique métier entre Android et iOS avec la multiplateforme Kotlin

Si un client souhaite que son activité soit présente et fructueuse sur les plateformes mobiles Android et iOS, une application mobile s’avère pratiquement incontournable. L’application permet de mieux tenir compte des besoins de l’utilisateur sur un smartphone qu’une simple page d’accueil. Les fonctionnalités natives de la plateforme comme les notifications push et l’intégration fluide de Google Pay et Apple Pay peuvent nettement améliorer l’expérience du client et avoir un impact sur la fidélisation de la clientèle et le succès d’une application. Aujourd’hui, les utilisateurs des diverses plateformes ont des attentes élevées en matière d’interface utilisateur. Cela leur permet de prendre rapidement leurs marques au sein d’une nouvelle application. Cela concerne notamment la navigation correcte dans l’application et le respect des directives liées à l’interface utilisateur de la plateforme concernée. Une application Android qui a été créée selon les directives iOS a généralement un impact négatif.

Les applications natives sont la référence absolue

Les consommateurs recherchent souvent un design sophistiqué avec des animations et l’utilisation des dernières nouveautés en matière de plateforme (p. ex. mode sombre). Et ce, de préférence, dès le jour de lancement de la nouvelle version OS. Avec ces exigences, une application native s’avère presque incontournable. Les fonctionnalités OS natives comme l’accès au lecteur d’empreintes digitales ou l’interface Bluetooth peuvent certes être utilisées avec d’autres solutions multiplateformes. Mais cela nécessite souvent un plug-in externe. Ce dernier ne provient pas de Google ou d’Apple et peut éventuellement contenir des erreurs.

Apple et Google ne sont pas non plus à l’abri des bugs. Mais en raison de leurs nombreux efforts de test et de leur vaste base d’utilisateurs, ces derniers sont vite repérés et éliminés. En revanche, concernant les plug-ins tiers, la question est de savoir si les erreurs éventuelles sont (rapidement) corrigées. Avec ces incertitudes, il est difficile de démarrer un projet ambitieux. Car un problème très important, voire insoluble, pourrait survenir en plein développement. L’utilisation de l’interface Bluetooth n’est pas anodine, même dans le cadre d’un développement natif. Mais de nombreuses ressources sont disponibles sur Internet grâce à une vaste communauté et une longue expérience du développement natif.

Les solutions multiplateformes sont encore très récentes et peu répandues. Pour cette raison, il est possible qu’il n’existe pas de solution à un problème.

Nous restons dans l’univers du natif

La multiplateforme Kotlin permet maintenant de partager le code de la logique métier et de conserver le reste dans l’univers natif correspondant. Le code partagé est géré comme une bibliothèque sur les deux plateformes. Cela permet aux développeurs de continuer à utiliser leurs outils et langages familiers. Mais également de continuer à accéder aux fonctionnalités OS natives. En cas de modification de la logique métier, les développeurs doivent simplement mettre la bibliothèque à jour. Il est également possible de migrer progressivement la logique métier vers une bibliothèque partagée.

L’interface utilisateur et l’expérience utilisateur restent donc totalement sous le contrôle de la plateforme native et de ses développeurs, qui possèdent des années d’expérience pour la gérer efficacement. Pour les nouvelles fonctionnalités de la plateforme comme le mode sombre, il suffit de mettre à jour l’interface utilisateur sans modifier la logique métier. Même en cas d’importantes mises à jour de la plateforme, comme une nouvelle option de développement de l’interface utilisateur (SwiftUI/Jetpack Compose), son utilisation ne pose aucun problème.

Les efforts partagés sont diminués de moitié

Le partage de la logique métier permet de ne la développer qu’une seule fois. Nous connaissons déjà la promesse du «développement unique pour une exécution sur les deux plateformes». Malheureusement, cette promesse nécessitait auparavant de faire des compromis, notamment d’effectuer de longs et coûteux ajustements de l’interface utilisateur/expérience utilisateur sur l’une des plateformes.

Lors du partage de la logique métier, la priorité est accordée à la logique métier et la mise en œuvre correcte. Il est donc possible de s’assurer que la logique sera exécutée comme il se doit sur les deux plateformes après une mise en œuvre correcte. Il arrive plus souvent que les applications présentent des erreurs diverses notamment lors du développement d’une application Android et iOS, car les développeurs peuvent avoir compris les exigences différemment ou les avoir implémentées incorrectement.

La logique métier à partager entre les plateformes est développée comme une bibliothèque Kotlin normale, à deux exceptions près. Les exceptions concernent la configuration du projet et l’utilisation de fonctionnalités Android et iOS natives dans le code partagé. Lors de la configuration, il est nécessaire de définir les plateformes à prendre en charge. Dans notre cas, il s’agit d’Android et d’iOS. Il existe de nombreux documents et outils d’aide à la configuration sur la page officielle du projet de multiplateforme Kotlin. La configuration n’est généralement nécessaire qu’une seule fois au début du projet.

En cas d’utilisation de fonctionnalités de plateforme natives, comme l’affichage de journaux sur Android à l’aide de Logcat et sur iOS avec NSLog, les deux mots clés expect et actual rajoutés à cet effet jouent un rôle capital. Cela permet, à l’instar d’une interface, de définir des signatures de méthodes, qui doivent à leur tour être implémentées en natif. Il est ainsi possible de mettre en œuvre des différences spécifiques à la plateforme dans la logique partagée. Cela s’avère pertinent pour les capteurs biométriques et les fonctions GPS, par exemple, car il existe de grandes différences entre les plateformes dans ces domaines.

Sous le capot

En cas d’utilisation de la bibliothèque sous Android, il est possible de créer une archive Android (AAR) qui peut être incluse dans un projet Android comme une dépendance normale. Le code peut également être intégré à un projet Android sous forme de sous-modules Git. Les deux solutions présentent des avantages et des inconvénients.

Pour utiliser la bibliothèque dans un projet iOS, le code est compilé dans un framework avec LLVM. Ainsi, le framework créé peut être utilisé dans les projets Objectiv-C et Swift et d’autres frameworks peuvent être intégrés à un projet.

It’s all about the money

Si un client opte pour une solution multiplateforme classique dès la planification d’une application, il a généralement à l’esprit les économies potentielles. Et les arguments sont solides dans ce domaine. Cependant, les aspects critiques sont souvent occultés et on promet monts et merveilles: «Développez en un clin d’œil une seule application pour les deux plateformes». Cela peut s’avérer correct pour les petites applications, mais pour les projets de grande envergure notamment, les économies initiales se transforment en montagnes de coûts.

Si la présentation de l’application doit être conviviale sur les deux plateformes, avec de belles animations et des transitions fluides entre les différents écrans, cet objectif devient très rapidement compliqué à atteindre avec les solutions multiplateformes communes. Les développeurs ont besoin d’une vaste connaissance de la plateforme concernée pour pouvoir mettre en œuvre ces exigences. Ils doivent non seulement connaître la solution multiplateforme, mais également les deux plateformes natives. Rien que pour cela, le développeur doit avoir des connaissances approfondies des trois plateformes et les maintenir à jour. Sur Android et iOS, une nouvelle mise à jour logicielle majeure est publiée chaque année, qui contient souvent de nombreuses fonctionnalités inédites.

Mais l’univers des solutions multiplateformes n’évolue pas moins rapidement que celui des solutions natives. De nouvelles solutions vont et viennent, et plus le temps passe, plus il devient difficile de leur trouver des développeurs car ils sont peut-être déjà passés à autre chose. Ce problème n’existe pas avec le développement natif. Un développeur natif connaît les anciennes et les nouvelles applications et est souvent un expert de sa plateforme. Il peut non seulement mettre en œuvre les exigences, mais aussi conseiller l’entreprise pour qu’elle tire le meilleur parti de la plateforme.

Sharing is caring

Pour nous, la multiplateforme Kotlin est incontournable. Le fait de se concentrer sur le partage de la logique métier est pour nous un avantage évident par rapport à d’autres solutions multiplateformes et au développement en silos (les solutions Android et iOS sont développées séparément, sans partage de code ou similaire). Les développeurs d’Android et d’iOS aiment beaucoup utiliser la multiplateforme Kotlin car cela ne change pas beaucoup leur manière habituelle de travailler. Ils peuvent également utiliser leurs connaissances sur la plateforme concernée pour développer de superbes applications avec des animations fluides, de belles transitions et des utilisateurs satisfaits.

Vous souhaitez en savoir plus sur des sujets intéressants du monde adesso ? Alors jetez un coup d'œil à nos articles de blog qui ont été publiés jusqu'à présent.