Nos clients nous demandent parfois quel est notre avis sur les solutions qui permettent de mutualiser du code, afin d’éviter d'écrire tout deux fois. Nous allons voir dans cet article, les solutions qui existent et ce qu’elles proposent que ce soit en terme de budget, de temps de développement ou de staffing. Sans ces solutions il est nécessaire de re-développer les mêmes fonctionnalités sur chacune des plateformes. L’entreprise doit alors écrire et maintenir plusieurs implémentations de code qui en théorie fait la même chose et il peut être difficile pour elles de s’accorder afin de pouvoir délivrer les mêmes fonctionnalités au même moment pour chaque plateforme.
Comme à son époque pour le monde PC, les solutions cross-platform ont fait leur apparition pour le monde mobile et abordent souvent le problème de manières différentes.
Chez Octo on recherche une solution qui permette de partager proprement du code entre Android & iOS. On porte une attention toute particulière aux critères de performance, de testabilité, d’expérience utilisateur ainsi qu’à l’engouement et à l’activité de la communauté.
Il existe énormément de solutions et chacune cherche à s’imposer. Certaines choisissent de sacrifier les performances au profit d’une mutualisation et d’une portabilité complète tandis que d’autres cherchent à maximiser les performances et l’interaction avec l’environnement natif quitte à ne mutualiser que certaines parties de votre application.
Le tableau suivant liste les solutions disponibles actuellement sur le marché :
De manière générale, les solutions cross-platform mobile se ressemblent beaucoup dans leur mode de fonctionnement pour la plupart et peuvent être rangées parmi trois catégories que je définirais ainsi :
Ces solutions doivent leur grande compatibilité aux technologies web. Elles produisent des webapps. Elles sont donc limitées en terme de performance, d’intégration et de fonctionnalités au sein de la plateforme dans laquelle elles évoluent. Elles n’ont pas d’accès aux API spécifiques de chaque plateforme, l’accès aux composants de l’appareil leurs sont également limitées. Ces solutions apportent également avec elles toutes les vulnérabilités liées aux technologies du web.
Leur plus grand atout est leur portabilité, elles permettent de rendre disponible une application sur un grand nombre de plateformes même au delà du monde mobile sur la base d’un seul et unique code. Il est indéniable que le temps de développement est largement réduit avec ce type de solution.
On pourra citer des solutions comme Cordova, Titanium qui semblent s'être imposées sur cette catégorie de solution. Qt et Kivy sont des cas particuliers qui pour leur part ne produisent pas de webapps mais essaient d’imiter le comportement des éléments natifs (boutons, checkbox,...) de l’environnement afin d’obtenir de meilleures performances qu’une webapp. (1)
Ce deuxième type de solution se propose de mutualiser le code métier en gardant native la gestion des vues. Toute la couche métier est alors développée indépendamment de la plateforme dans laquelle elle évolue sur la base d’un seul et même code tandis que la couche s’occupant de l’interface utilisateur appel les éléments natifs à chaque plateforme. Le but est ici de dégrader le moins possible les performances et de conserver une expérience utilisateur optimale qui sont les deux reproches faites aux solutions full cross-platform.
On pourra citer des solutions comme React Native ou Xamarin mais aussi Flutter ou Ionic qui semblent prometteurs.
Le but ici est de maximiser les performances en ne mutualisant que certaines fonctionnalités de l’application (ie : un algorithme de tri particulier, un traitement spécifique sur un jeu de donnée, etc).
Pour ce type de solutions les performances sont au rendez-vous et la gestion des vues reste également native. On intègre le code cross platform sous forme de librairies annexes permettant ainsi à notre projet de garder l’accès aux fonctionnalités spécifiques à chaque plateforme (via le SDK dédié).
On note qu’avec ce type de solutions la mutualisation n’est pas complète et que certaines parties de l’application seront toujours écrites en plusieurs exemplaires. Ces solutions utilisent généralement des langages comme Golang ou C++ que l’on devra encapsuler à notre projet en produisant du code JNI ou Objective-C++. (2)
Chez Octo les projets suivent le principe de Clean architecture[1]. La structure du projet est alors découpée en couches. Une couche Repository, qui s’occupe de récupérer les données. Une couche Core, qui s’occupera de traiter les données que lui aura précédemment transmise la couche Repository. Et enfin la View qui s’occupe uniquement de présenter les données qui lui sont transmises à l’aide de son Presenter.
On remarque que chaque couche a une tâche spécifique. Par exemple la couche Core ne fait que traiter des données grâce aux règles métiers qu'elle contient. Cette couche doit pouvoir être agnostique de la technologie et donc être écrite en n’importe quel langage. Pourquoi ne pas essayer de mutualiser cette couche dans ce cas ? Les interactors représentent les règles métiers et sont rattachés au Core. Leur fonctionnement est identique que ce soit sur Android et iOS, ils traitent les données de la même manière, et il parait rébarbatif de réécrire ces interactors deux fois.
L'idéal serait de pouvoir mutualiser certains composants de cette architecture et la solution featured cross-platform semble à première vue la mieux adaptée. Elle a l’avantage d’être assez souple et n’implique pas, contrairement aux deux autres, de dépendances fortes jusqu’au niveau du controller. Cette plus grande souplesse pourrait permettre de conserver cette structure de Clean Architecture tout en mutualisant du code entre Android et iOS.
Ok, dans les faits cela fonctionne mais quelqu’un a-t-il réellement entrepris d’utiliser ce type de solutions pour de vrais projets ? On sait que les projets client demandent une exigence toute particulière et intégrer une solution cross-platform ne doit pas se faire au détriment de la productivité de l’équipe. La réponse est oui.
Durant la CppCon 2014[2], Dropbox a annoncé avoir entrepris des travaux autour de la mutualisation de code entre iOS & Android. Ils ont commencé par faire l’expérience sur leur application de gestion de photos, Carousel, puis ont entrepris de mutualiser une partie de leur application iOS Mailbox en C++ au moment du portage de cette même application sur l’environnement Android. Ils sont d’ailleurs à l’origine de l’outil Djinni qui permet de générer des wrappers afin d’intégrer votre code C++ à vos projets iOS/Android.
Ensuite Facebook et LinkedIn ont tous deux commencé avec une application full-cross platform avant d’abandonner au vu des performances et de l’expérience utilisateur qui s’en trouvait dégradée. Cependant Facebook utilise React Native pour son application Ads Manager de même que Soundcloud.
Finalement beaucoup d’entreprises se tournent vers le full-cross-platform pour des questions de portabilité et de budget. Ces solutions possèdent aussi le plus haut chiffre d’abandon par ces sociétés..
Les avantages du cross platform semblent évident et ils permettraient de réduire le temps de développement d’un projet qui souhaiterait posséder une application sur les deux environnements, à savoir Android et iOS. Est-ce vraiment avantageux ? Chez Octo nous travaillons avec le concept de Clean Architecture mais pas seulement ! Tout le déploiement est entièrement automatisé et si une solution cross-platform venait à casser ce processus ce serait une perte de temps et de productivité importante même au vue des avantages que le cross-platform apporterait. Il est donc impératif que cette solution cross-platform s’intègre dans ce processus d'intégration continue.
