Comment choisir la bonne technologie pour du développement multiplateforme ?
Ces dernières années ont été marquées par l’essor de solutions de développement mobile multiplateforme, chacune se revendiquant comme “LA solution” permettant de réduire les coûts, raccourcir les délais de développement, faciliter la testabilité ou encore augmenter la cohérence entre les différentes plateformes cibles.
En résumé, toutes promettent de faire plus avec moins et, à les croire sur parole, on pourrait se demander pourquoi certains s’entêtent encore à utiliser les solutions dites « natives ».
Bien entendu, la réalité est plus complexe.
Toutes ces solutions vous imposent de faire des compromis. Elles ont certes des avantages mais aussi des inconvénients. Les utiliser implique de comprendre et d’accepter ces compromis et de courir certains risques qu’il faut balancer avec les gains potentiels.
Comment s’y retrouver et évaluer objectivement ces solutions ?
Nous vous proposons ici un ensemble de critères permettant d’en évaluer les forces et faiblesses. En fonction de vos objectifs et des compromis que vous êtes prêt à faire, ces critères vous permettront de choisir une solution multiplateforme pour votre projet.
Performances
Tous les utilisateurs apprécient une application performante: l’application démarre et est utilisable en un instant, les interactions sont riches, fluides et réactives.
L’utilisateur final ne se soucie ni comment ni avec quelle technologie vous avez construit votre application. Par contre, une application lente ou peu réactive sera sanctionnée immédiatement d’une mauvaise note, d’une désinstallation ou encore d’un désintérêt.
Malheureusement, c’est un des points de souffrance récurrents des solutions multiplateformes, notamment celles basées sur des technologies Web.
Quelques questions à se poser:
Le temps de démarrage avant interaction des applications est-il augmenté ?
Les applications produites par la solution sont-elles fluides et réactives ?
Des ralentissements ou des latences sont-ils perceptibles ?
Des animations complexes sont-elles possibles de manière performante ?
Les changements d’orientation et redimensionnements de l’écran sont-ils performants ou montrent-t-il des latences ?
Afin d’évaluer ce point, pensez à tester plusieurs appareils, de plateformes et de gammes différentes. Par exemple, certaines solutions se comportent relativement bien sur des iPhone dernier cri mais offrent une expérience inacceptable sur un téléphone Android bas de gamme.
Compromis possibles
Revoyez les ambitions graphiques à la baisse afin de garder des performances acceptables.
Soyez prêt à changer ou simplifier le rendu / les animations en fonction des retours de l’équipe de développement.
Consommation
La consommation de la batterie est un point souvent négligé mais très important pour les utilisateurs.
Un téléphone déchargé ne sert à rien et les applications les plus gourmandes en énergie sont montrées du doigt par le système, incitant les utilisateurs à les désinstaller avant de publier un commentaire assassin.
Quelques questions à se poser:
La consommation de la batterie est-elle similaire à une application native équivalente ?
Compromis possible
Revoir ses ambitions graphiques, de traitement ou de rafraîchissement à la baisse.
Taille
La taille d’une application a aussi un impact sur les utilisateurs.
Il n’est pas rare de manquer de place sur un appareil et de devoir supprimer, entre autres, des applications, les plus volumineuses étant naturellement les premières victimes potentielles.
Certaines fonctionnalités comme Instant Apps (qui permet d’installer des parties d’applications depuis Chrome sur un téléphone Android de manière transparente) limitent, par exemple, la taille des fonctionnalités à 4 mégaoctets.
Quelques questions à se poser:
La solution a-t-elle un impact significatif sur la taille des applications générées ?
Les utilisateurs devront-ils télécharger l’application dans un contexte de faible connectivité (pays émergents, itinérance, coûts élevés…) ?
Le projet bénéficierait-il d’une compatibilité Instant Apps ?
Mise à jour à distance
Une des difficultés liée à la maintenance d’une application mobile est la gestion des ses mises à jour et de ses différentes versions.
Contrairement à un site web qui est mis à jour (presque) en temps réel pour tous les utilisateurs, la mise à jour d’une application mobile passe par un ensemble d’étapes:
validation par les magasins d’applications
propagation des nouvelles versions sur les serveurs du magasin d’applications avant d’être effectivement visibles par les utilisateurs
le bon vouloir de l’utilisateur pour effectuer une mise à jour manuelle ou les bonnes conditions (typiquement appareil en recharge et en wifi) pour le déclenchement d’une mise à jour automatique (si activée)
Certaines solutions multiplateformes permettent de mettre à jour les applications à distance de manière quasi instantanée (p.ex. au prochain démarrage de l’application). Cela peut être très pratique pour diffuser un correctif en urgence ou si l’application n’est pas distribuée via un magasin d’applications et ne dispose donc pas d’un mécanisme de mise à jour existant.
Néanmoins, il convient aussi de tempérer et d’exposer les limitations:
Seule la partie multiplateforme peut être mise à jour. Si une mise à jour d’un composant natif est nécessaire, l’application devra être mise à jour classiquement.
Les magasins d’applications qui imposent une validation des applications et de leurs mises à jour (typiquement Apple), pourraient voir ces systèmes d’un mauvais oeil et comme une manière d’outrepasser les règles, exposant l’application et son éditeur à des sanctions.
La possibilité d’une modification du code à distance est un risque de sécurité supplémentaire à prendre en compte.
La gestion des mises à jour est plus complexe et le risque d’erreur plus grand. En cas de mise à jour partielle, une mise à jour complète devra quand même être publiée sur le canal classique de mise à jour. Il faut aussi vérifier que la mise à jour partielle est bien compatible avec les versions ciblées (par exemple que les composants natifs embarqués sont bien compatibles avec la mise à jour).
Quelques questions à se poser:
Mon application est-elle publiée sur un magasin d’applications ne proposant pas de mécanisme de mise à jour automatique ou n’est-elle pas publiée sur une magasin d’applications ? Certains magasins d’applications proposent des solutions pour encourager l’utilisateur à mettre à jour votre application voire à effectuer la mise à jour depuis l’application (par exemple[ in-app updates de Google](https://developer.android.com/guide/app-bundle/in-app-updates)). Dans ce cas, le support d’une solution tierce et partielle (ne permettant pas de mettre à jour la partie native) n’a que peu d’intérêt.
Mon projet a-t-il besoin d’avoir un mécanisme automatique de mise à jour à distance ? Les temps de validation des applications par les magasins d’applications sont passés de plusieurs semaines à quelques jours. Il faut garder en tête que le support de mises à jours partielles à distance n’est pas totalement gratuit et aura un coût d’exploitation et de maintenance en temps de travail de l’équipe de développement.
Fonctionnalités spécifiques à certaines plateformes
Les solutions multiplateformes unifient plutôt bien ce que toutes les plateformes ont en commun: télécharger des données, afficher des composants graphiques tels que des listes, des images, des boutons, etc.
Néanmoins les fonctionnalités qui ont un grand facteur différenciant ou qui sont absentes de certaines plateformes sont beaucoup plus complexes à unifier.
Par exemple: traitement en tâches de fond, les notifications, les widgets, les API spécifiques aux magasins d’applications (in-app purchases, etc.), support d’appareils spécifiques (montres connectées, télévisions,..), API bas-niveau, etc.
Quelques questions à se poser:
Mon application a-t-elle besoin de fonctionnalités non prêtes à l’emploi dans la solution envisagée ?
Ces fonctionnalités sont-elle réalisables dans le cadre de la solution étudiée et à quel coût ?
Existe-t-il des librairies tierces qui répondent aux besoins des fonctionnalités ? Sont-elles maintenues et de qualité ?
Une solution de contournement est-elle possible ?
Support et communauté
La santé d’une solution multiplateforme est directement liée aux efforts et au support de son sponsor et contributeur principal.
Le risque est de choisir une solution qui sera plus tard abandonnée ou négligée ne laissant à votre projet que peu d’espoir de pouvoir continuer à évoluer sans une réécriture totale.
Un autre facteur important est la réactivité et la rapidité avec laquelle la solution adopte les nouveautés des plateformes natives et corrige ses bugs connus. Que se passera-t-il si le mainteneur de la solution décide qu’il n’est pas opportun pour lui de supporter certaines fonctionnalités ou de corriger certains bugs dont votre application dépend dans des délais acceptables pour vous ? Pourrez-vous adresser ces manquements vous-même ?
D’autres gros contributeurs, sponsors ou utilisateurs sont aussi un indicateur à prendre en compte. Néanmoins, l’histoire récente a montré que certaines grandes compagnies qui s’investissent très activement dans des solutions multiplateformes peuvent effectuer, quelques mois plus tard, un virage à 180 degrés en les abandonnant complètement. La popularité est un indicateur mais attention de ne pas tomber dans un argumentum ad populum.
Enfin, la santé et le dynamisme de l’écosystème est un facteur à prendre en compte.
Existe-t-il des librairies tierces de qualité répondant aux besoins des utilisateurs non pris en charge par la solution ? Malheureusement c’est un des points de souffrance des solutions multiplateformes surtout si on les compare à la qualité et diversité des librairies tierces disponibles pour les plateformes natives. Les raisons sont simples: premièrement, ces solutions sont moins populaires que les plateformes natives. Il y a donc moins de développeurs désireux de contribuer. Deuxièmement, la réalisation d’une librairie multiplateforme requiert des connaissances dans la solution multiplateforme concernée mais aussi dans les plateformes natives qu’elle cible. Pour unifier les comportements ou fonctionnalités natives il faut une connaissance très approfondie des plateformes sous-jacentes. Il n’est ainsi pas rare de voir des librairies dite “multiplateformes” ne supportant réellement bien qu’une seule plateforme.
Quelques questions à se poser:
La solution est-elle open source ?
La solution a-t-elle des bugs connus non résolus qui pourraient impacter votre projet ?
La solution est-elle activement supportée par son créateur ou contributeur principal ?
La communauté autour de cette solution est-elle dynamique et active ?
La solution est-elle populaire ou en perte de vitesse ?
Est-ce qu’il existe des librairies de qualité dont mon projet a besoin qui sont activement supportées ?
Le créateur est-il à l’écoute des problèmes que ses utilisateurs peuvent rencontrer ?
La solution est-elle bien documentée ?
Homogénéité entre plateformes et versions d’OS
L’écosystème mobile natif actuel existe depuis une dizaine d’années.
Le design, les fonctionnalités et les comportements ont évolué à travers les différentes versions des systèmes d’exploitation. Heureusement, le parc actif n’est pas aussi ancien mais peut quand même comporter des appareils et versions de systèmes d’exploitation vieux de cinq ans.
Le défi est de s’assurer qu’une application réagira de la même façon sur toutes les versions d’une plateforme donnée.
C’est un problème courant en développement natif qui est adressé différemment en fonction du constructeur. Par exemple, Android souffrant d’une adoption plus lente des dernières versions sur la majorité des mobiles (souvent appelée la fragmentation d’Android), Google investit beaucoup dans des librairies dites de compatibilité afin d’apporter les nouveautés sur les vieilles versions du système ou d’en simplifier la dégradation gracieuse. Apple, d’un autre côté, n’ayant pas ce problème de fragmentation, a tendance à plus ou moins forcer l’adoption de la dernière version de son système d’exploitation par les utilisateurs et les développeurs, laissant à ces derniers la tâche de gérer les différences s’ils veulent maintenir une certaine rétrocompatibilité.
Les solutions multiplateformes démultiplient ce problème.
Il ne s’agit plus de garantir l’homogénéité à travers une seule plateforme mais à travers toutes les plateformes supportées.
A noter que toutes n’ont pas la même stratégie à ce niveau. Certaines choisissent de ne rien faire. Par exemple, un simple bouton pourra avoir un rendu différent entre différentes plateformes natives et entre différentes versions d’une même plateforme native. D’autres choisissent d’investir beaucoup d’efforts pour garantir une certaine homogénéité et simplifier le travail des développeurs.
Gardez à l’esprit que l’aspect visuel n’est que la partie émergée de l’iceberg.
Ce sont les différences de comportement subtiles, présentes aux cas limites et difficiles à identifier en amont qui peuvent sérieusement impacter votre projet.
Quelques questions à se poser:
Est-ce que l’homogénéité de l’interface utilisateur est importante pour mon projet ?
Est-ce que la solution multiplateforme étudiée garantit une homogénéité de l’interface utilisateur et des comportements à travers les différentes plateformes et versions des systèmes d’exploitation ?
Fidélité et intégration au sein des plateformes cibles
Bien qu’il soit important que votre application ait sa propre identité visuelle, il est tout aussi important qu’elle respecte la philosophie et les codes des plateformes cibles.
La navigation, la physique et dynamique des interactions, l’utilisation de certaines icônes, la typographie et l’alignement de certains éléments sont autant de partis pris des concepteurs des plateformes natives qui servent de repères aux utilisateurs.
Il ne s’agit pas de porter un jugement de valeur sur les choix effectués.
On peut préférer le parti pris d’une plateforme ou d’une autre mais il est dans l’intérêt de votre application de les respecter autant que possible. Dans le cas contraire, elle donnera à l’utilisateur un sentiment de dissonance, de moindre qualité, de manque de professionnalisme ou encore de manque de considération de la plateforme cible et donc de ses utilisateurs.
En résumé, les utilisateurs ne se soucient pas de la technologie que vous choisissez pour développer votre application pour autant qu’ils ne s’en rendent pas compte.
Quelques questions à se poser:
Les applications produites par la solution multiplateforme respectent-elles les codes et s’intègrent-elles facilement dans l’écosystème natif cible ?
Les applications produites par la solution multiplateforme sont-elles facilement distinguables des applications natives ?
La solution permet-elle une différenciation par plateforme simple ou compliquée ?
Outillage
Les outils de développement natifs sont aujourd’hui non seulement gratuits mais d’une très grande qualité. Google et Apple améliorent sans cesse ces outils afin d’augmenter la productivité de leurs développeurs.
C’est un sujet extrêmement vaste. On peut citer par exemple: l’auto-complétion, le débogage, l’analyse statique de code, la gestion des tests, le profilage, …
Même si en théorie un simple éditeur de texte suffit pour écrire une application, le support d’outils professionnels permet d’augmenter le confort et la productivité de votre équipe de développement. C’est donc un point crucial à prendre en compte.
Quelques questions à se poser:
La solution étudiée propose-t-elle des outils de développement et de débogage stables et de qualité ?
La solution étudiée s’intègre-t-elle facilement dans un processus d’intégration continue ?
Quel impact la solution aura-t-elle sur l’organisation du code source et de votre logiciel de gestion des versions ?
Est-ce que la solution étudiée facilite ou complexifie les tests unitaires et d’intégration ?
Facilité de ponts avec la partie native
Il est probable que, tôt ou tard, le code multiplateforme devra interagir avec du code natif.
Par exemple, une fonctionnalité native non supportée par la solution multiplateforme devra être développée ou encore une librairie tierce (publicités, outils de statistiques, …) ne supportant pas la solution choisie devra être pilotée depuis le code multiplateforme.
Pour répondre à cette problématique, la plupart des solutions multiplateformes permettent d’établir des “ponts” entre la partie native et multiplateforme.
On peut identifier deux types de ponts.
Ceux qui permettent d’utiliser des composants graphiques natifs dans la solution multiplateforme et ceux qui n’échangent que des données.
Les premiers sont en général plus compliqués et peuvent poser plus de problèmes à certaines solutions multiplateformes que les derniers. Néanmoins, utiliser un pont peut avoir un certain coût en terme de performance en fonction de la solution choisie.
Quelques questions à se poser:
Est-il facile de développer un pont entre la solution multiplateforme et les plateformes natives ?
Les ponts et particulièrement les ponts graphiques ont-ils des limitations particulières ?
L’utilisation de ponts a-t-elle un impact sur les performances ?
Rapidité de développement
Une des promesses des solutions multiplateformes est de pouvoir développer plus vite une application qui cible plusieurs plateformes en même temps.
Mais qu’en est-il du temps de développement d’une application sur une plateforme ?
En d’autres mots, est-ce que la solution étudiée permet de développer et itérer plus vite ou moins vite qu’avec une approche native ?
L’outillage joue ici un rôle essentiel mais le choix du langage, de modèles architecturaux ou certaines fonctionnalités comme le rechargement à chaud peuvent réellement influencer le temps de développement.
Quelques questions à se poser:
La solution étudiée facilite ou complique-t-elle le développement ?
La solution étudiée propose-t-elle un rechargement à chaud fiable ?
Réutilisation de compétences ou de technologies
Certaines solutions mettent en avant l’utilisation d’un langage ou d’une technologie connue dans d’autres contextes.
La promesse est de pouvoir réutiliser des connaissances durement acquises et ne rien devoir apprendre ou presque.
Bien qu’utiliser un langage ou une technologie connue soit confortable, baser son choix de solution multiplateforme principalement sur ce critère serait une erreur. Les aspects performance, consommation, taille et fidélité sont bien plus importants aux yeux des utilisateurs finaux que la technologie utilisée.
Les langages ou les modèles architecturaux ne forment que la partie émergée de l’iceberg. Un langage peut s’apprendre en quelques jours (voire moins) et cela n’est rien en comparaison du coût d’un mauvais choix technique à moyen et long terme.
Toutes les solutions multiplateformes, même celles basées sur des méthodes de développement web ont des spécificités non triviales qu’il est nécessaire d’appréhender.
Développer une application multiplateforme requiert de bien connaître les plateformes cibles. N’importe quel projet un peu complexe nécessitera, tôt ou tard, le développement d’un pont natif. Certains choix techniques seront bien plus éclairés si l’équipe de développement a conscience des forces et faiblesses des plateformes sous-jacentes. Les équipes de développement multi-plateformes doivent, dès lors, avoir encore plus cette curiosité qui caractérise les bons développeurs.
Malheureusement, certains tombent dans le piège de la facilité apparente et encense des technologies (bonnes ou mauvaises) pour de mauvaises raisons.
En résumé, la possibilité de réutiliser des compétences acquises préalablement est un plus mais ne devrait pas occulter les facteurs plus importants liés à la qualité des applications produites par les solutions étudiées.
Quelques questions à se poser:
La solution étudiée permet-elle de réutiliser des compétences disponibles de l’équipe de développement ?
Cela représente-t-il un gain appréciable et quantifiable ?
La solution étudiée implique-t-elle un coût de formation de l’équipe de développement ?
Est-il facile ou difficile de recruter des experts dans la solution étudiée ?
Partage de la logique métier et des interfaces utilisateurs
Certaines solutions multiplateformes permettent de partager uniquement la logique métier, d’autres de partager à la fois la logique métier et les interfaces graphiques, certaines encore, de partager la logique métier mais demandent d’écrire des interfaces graphiques propre à chaque plateforme cible dans un langage commun.
Chaque approche a ses avantages:
Partager uniquement la logique métier est indiqué si votre application a des règles métier complexes. En effet, ce partage aura un coût en terme de réflexion (il faut penser à plusieurs plateformes en parallèle), d’intégration (comment répercuter une modification de la logique métier dans la partie spécifique à la plateforme) et d’organisation. Néanmoins, c’est la solution qui offre aussi le plus de souplesse.
Partager la logique métier et les interfaces graphiques est la solution qui permet la meilleure économie d’échelle à condition, bien entendu, que cette solution le fasse bien (performance, fidélité, …) et que les compromis choisis vous conviennent.
Enfin partager la logique métier et écrire les interfaces graphiques spécifiques par plateforme dans un langage commun n’a que peu d’intérêt en soit. Elle a à la fois le désavantage de devoir écrire le code des interfaces graphiques autant de fois que de plateformes souhaitées et d’être dépendant de la solution choisie pour utiliser des fonctionnalités natives. Le seul avantage est de pouvoir utiliser un seul langage mais, comme déjà exposé, le gain n’est pas évident.
Quelques questions à se poser:
Est-ce que la logique métier de mon application est complexe ?
Mon application a-t-elle des règles spécifiques en fonction des plateformes ?
Est-ce que je souhaite seulement partager la logique métier ou aussi les interfaces utilisateurs ?
La solution ralentit-elle le développement et le cycle d’itération ?
