Écrivez une fois, déployez partout : quand passer au natif ?

Write Once, Deploy Everywhere (WODE) a été la promesse de nombreux frameworks de développement au cours de la dernière décennie, dont l'objectif est de faciliter l'écriture de plusieurs applications natives. Déterminer la voie à suivre est l'une des décisions les plus critiques qu'un chef de projet doit prendre en raison de son coût de démarrage élevé, de son impact sur l'équipe de développement et de l'impossibilité potentielle de revenir en arrière.

Les solutions hybrides telles que Ionic tirent parti des technologies Web pour rendre les applications sur toutes les plates-formes, mais souvent, le produit final ne répond pas aux attentes de l'utilisateur en matière d'apparence native .

Cependant, même le terme «natif» a récemment été brouillé par des frameworks qui compilent jusqu'au code natif (par exemple, React Native, Xamarin, etc.).

Cet article décompose les avantages et les inconvénients de diverses voies de développement mobile et les compare à la composition de l'équipe, au coût et à l'expérience utilisateur dans le but de permettre aux chefs de produit de prendre une décision plus éclairée.

Écrivez une fois, déployez partout

Le concept Write Once, Deploy Everywhere fait référence à la capacité d'une équipe de développement à écrire une application une seule fois - en utilisant une pile de développement unique, abstraite de la ou des plates-formes sur lesquelles l'application sera déployée - tout en conservant la capacité de déployer l'application sur toutes les plates-formes souhaitées, par exemple Android, iOS, Windows, etc. Idéalement, cela est accompli sans sacrifier la maintenabilité, les performances ou l'expérience utilisateur (UX).

La méthode alternative - et historique - de développement d'applications mobiles implique le processus simple consistant à simplement écrire une application distincte pour chaque plate-forme, ce qui, bien sûr, entraîne son propre coût potentiel élevé en temps et en ressources.

En général, les facteurs à prendre en compte lors du choix d'un chemin de développement incluent :

• Ancienneté du projet
• Composition et taille de l'équipe de développement
• Plate-forme(s) souhaitée(s) pour la distribution
• Délai de mise sur le marché requis
• Bande passante disponible pour passer à un autre chemin si nécessaire

Malheureusement, appliquer chacun de ces facteurs à chacune des voies disponibles, ainsi que parcourir la myriade d'opinions disponibles sur le sujet, peut être assez décourageant. De plus, ce processus laisse souvent le chef de projet avec un sentiment d'incertitude quant à la meilleure voie pour répondre aux exigences de l'application.

À un niveau élevé, les différentes voies de développement mobile peuvent être classées en deux catégories : natif ou WODE, c'est-à-dire natif ou tout le reste. En termes simples, soit on écrit une application native, soit on ne le fait pas. La catégorie WODE est en outre divisée en deux groupes :

• Frameworks hybrides - ceux qui exploitent les technologies Web pour rendre des applications sur plusieurs plates-formes.
• Frameworks non hybrides - ceux qui utilisent des composants d'interface utilisateur natifs (par exemple, des boutons, des champs de texte et même des gestionnaires de mise en page) au lieu de rendre une vue Web à l'intérieur d'une application comme le font les frameworks hybrides.

La majorité des frameworks WODE sont hybrides ; cependant, afin d'améliorer à la fois les performances et les limitations UX des frameworks hybrides tout en offrant les avantages d'un framework WODE, la tendance actuelle est aux non hybrides . En raison de cette tendance, des frameworks tels que React Native, Xamarin et Appcelerator gagnent en popularité.

Chacun de ces chemins (natifs, hybrides et non hybrides) présente des forces et des faiblesses différentes et, par conséquent, chacun a des cas d'utilisation différents pour lesquels il est le plus adapté. Le reste de cet article décompose les avantages et les inconvénients de chaque voie de développement mobile en tenant compte des priorités concurrentes telles que la composition de l'équipe, le coût du projet et l'UX. À l'exception de quelques cas d'utilisation spécialisés, l'écriture d'applications natives maximise l'expérience utilisateur à un coût légèrement plus élevé.

En général, l'adage « vous en avez pour votre argent » s'applique, donc si le coût compte plus que l'expérience des clients, le natif n'est peut-être pas le bon choix. Cependant, une fois que l'UX devient vitale, les applications natives deviennent le choix évident car, pour améliorer l'UX, les applications basées sur WODE entraînent un coût considérable en temps ou en expertise native, ce qui va à l'encontre de l'objectif de choisir une application non native. voie de développement en premier lieu.

De plus, même si ce coût est payé, le produit final basé sur WODE fournira toujours un UX inférieur par rapport à son homologue natif. Par conséquent, le natif est presque toujours le bon choix pour la plupart des équipes de développement et pour la plupart des projets.

Applications natives

Les applications natives sont écrites dans le langage de base de la plate-forme donnée. Par exemple, les applications Android sont écrites en Java, tandis que les applications iOS sont écrites en Obj-C ou en Swift. Ils exigent que l'ingénieur de développement comprenne le langage ainsi que les nuances spécifiques à la plate-forme, qui incluent, par exemple, l'intégration de packages tiers, la gestion de la mise en page, l'interaction du système d'exploitation (OS), etc.

Avantages

Hautement personnalisable . Étant donné que chaque application est écrite à l'aide de composants natifs, la seule limite à la personnalisation est l'interface avec les frameworks sous-jacents, et parfois même pas. Comme la plupart des ingénieurs de développement natifs en attesteront, il existe souvent un moyen d'accomplir une tâche donnée malgré une interface limitée.

Une preuve simple de cette idée peut être trouvée en parcourant les communautés de support pour une plate-forme donnée. On trouvera de nombreux exemples de la façon d'accomplir une tâche qui pourrait être «hors réserve», malgré les limites des cadres sous-jacents.

Un exemple concret d'iOS d'une telle tâche apparemment simple pourrait être d'afficher une superposition plein écran, surtout des éléments d'interface utilisateur externes, par exemple, une barre d' onglets , une barre de navigation, etc. couche d'interface utilisateur normale actuellement présentée. En tant que tel, pour avoir une superposition plein écran, il doit être ajouté au calque masqué au-dessus de la barre d'onglets dans la pile de vues. Ce type de personnalisation n'est généralement possible que sur les applications natives.

Performances les plus élevées . Comme prévu, une application native établit la référence en matière de performances. Étant donné que la plupart des autres types de framework ajoutent une ou plusieurs couches intermédiaires, ils s'exécutent par nature plus lentement qu'une application native.

Le plus maintenable . Les systèmes d'exploitation changent constamment. Point final. Lorsqu'ils le font, selon que des modifications importantes ont été apportées, une application doit être mise à jour en temps opportun afin de ne pas perdre la partie de sa base d'utilisateurs qui passe au système d'exploitation le plus récent. Évidemment, moins il s'écoule de temps entre le moment où le changement est mis à la disposition de ses utilisateurs et celui où une application est mise à jour, mieux c'est. Ce temps est minimisé lorsqu'il n'y a pas de dépendances à mettre à jour pour supporter ce nouvel OS, ce qui est le cas lorsque l'on travaille sur une application native.

Les inconvénients

Ressources supplémentaires . Lors de l'écriture d'applications pour plusieurs plates-formes, une équipe de développement se compose généralement d'un ou plusieurs ingénieurs en logiciel mobile pour chaque plate-forme prise en charge. Ceci, bien sûr, augmente intrinsèquement la taille et le coût d'une équipe de développement. Cela nécessite également que l'équipe d'ingénieurs ait une variété de compétences, par opposition à une base de compétences homogène. Cela a le potentiel de fragmenter une équipe en ce qui concerne le soutien et la collaboration.

Cycle de développement plus lent . Les applications natives ont le potentiel d'avoir un cycle de développement plus lent simplement parce qu'une application distincte doit être écrite pour chaque plate-forme souhaitée. Le cas extrême est celui où il n'y a qu'un seul ingénieur en développement mobile dans l'équipe puisque chaque application est essentiellement écrite en série.

Faibles performances . Il peut sembler étrange d'avoir des performances à la fois pour et contre. D'une part, les applications natives donnent au développeur suffisamment d'espace pour créer une application finement réglée et performante. D'un autre côté, cependant, ils donnent également au développeur suffisamment de corde pour se pendre. S'ils ne savent pas ce qu'ils font, ils se retrouveront au mieux avec une application inférieure à la moyenne.

Remarque : En général, cela s'applique à tous les chemins de framework (natifs, hybrides et non hybrides). Si les ingénieurs qui développent une application n'ont pas les compétences nécessaires pour ce qu'ils tentent, l'application résultante ne répondra probablement pas aux exigences de conception et ne sera probablement pas bien acceptée par les utilisateurs.

Applications hybrides

Les applications hybrides sont généralement écrites à l'aide de HTML/CSS/LESS pour concevoir l'interface utilisateur : le « V » dans le modèle de conception MVC. Le "C", ou contrôleur, est alors généralement écrit en JavaScript - idéalement, en utilisant un framework JavaScript MVC tel que AngularJS. L'utilisation d'un framework comme AngularJS permet une meilleure séparation des classes et des responsabilités que ce qui est généralement possible en utilisant uniquement jQuery.

Un exemple de ce type de pile de framework hybride serait une couche de vue ionique soutenue par AngularJS, qui est finalement convertie et rendue dans une vue Web sur la plate-forme souhaitée à l'aide de PhoneGap et Cordova. De toute évidence, ce type de cadre WODE se fait au prix d'une complexité accrue.

De plus, l'utilisation de JavaScript entraîne ses propres limitations basées sur la conception et des problèmes liés au langage. Le but de cet article n'est pas de débattre des mérites ou des défauts d'une langue en particulier ; cependant, en tant que chef de projet, le choix d'utiliser JavaScript dans sa pile technique mobile ne doit pas être fait à la légère. Voici quelques exemples d'articles bien écrits sur les raisons pour lesquelles JavaScript doit être évité si possible :

• Le problème JavaScript
  
• Pourquoi je ne suis pas un développeur React Native

Avantages

Equipe de développement minimale . Les frameworks hybrides permettent à une petite équipe de développement, et en particulier à une équipe dont la base de connaissances principale est le développement Web, de produire rapidement des applications simples sur plusieurs plates-formes. Cela permet à un chef de projet de garder son équipe petite et de supprimer le besoin pour son équipe d'apprendre les langages natifs et les frameworks pour plusieurs plates-formes.

Cycle de développement plus rapide . En plus d'une équipe plus petite, les frameworks hybrides permettent un cycle de développement plus rapide lors du déploiement sur plusieurs plates-formes, car une seule couche de vue doit être conçue à l'aide des technologies Web.

Les inconvénients

UX potentiellement médiocre . L'inconvénient de n'avoir à écrire qu'un seul calque de vue est qu'il ne reste qu'un seul calque de vue. Cela peut entraîner une mauvaise UX, car une approche unique de la conception de l'interface utilisateur ne parvient pas à donner à l'application une apparence confortable et familière aux utilisateurs sur toutes les plates-formes. De plus, étant donné que les applications hybrides sont essentiellement une vue Web intégrée à l'interface utilisateur, cela peut donner aux utilisateurs l'impression qu'ils consultent réellement une page Web au lieu d'interagir avec une application native. Cette expérience a presque toujours un impact négatif sur la satisfaction des utilisateurs et, en fin de compte, sur la rétention.

Coûteux à personnaliser . L'amélioration de l'expérience utilisateur en concevant des interfaces utilisateur personnalisées pour chaque plate-forme se traduit par des cadres d'interface utilisateur complexes et uniques qui peuvent être coûteux à créer et difficiles à maintenir au fil du temps. De plus, afin de créer des éléments d'interface utilisateur qui permettront à une application de se démarquer (par exemple, une animation, des vues personnalisées, etc.), des composants de pont personnalisés doivent être créés pour traduire la conception de l'interface utilisateur de haut niveau en quelque chose que le cadre de niveau inférieur , comme Cordoue, comprendra. En général, plus on personnalise et améliore l'UX d'une application hybride, plus cela diminue le bénéfice d'un cycle de conception rapide et peu coûteux.

Des performances moindres . Étant donné que les applications hybrides restituent les vues de l'application dans une vue Web, il existe un grand potentiel de faire des erreurs de mise en œuvre lorsqu'il s'agit de cadres de système d'exploitation (par exemple, réseau, Bluetooth, contacts sur l'appareil, etc.), ce qui entraîne une dégradation considérable des performances. A noter également que, même si un grand soin est apporté aux performances puisque tout est affiché via une webview, les performances maximales des applications hybrides seront toujours légèrement inférieures à celles de leurs homologues natives.

Gestion des plugins non triviale . Vous souvenez-vous de ces fonctionnalités personnalisées que l'équipe de conception a passé des semaines à peaufiner, suivies de quelques semaines supplémentaires pendant que l'équipe de développement créait les composants de pont nécessaires pour que Cordova puisse travailler avec eux ? Eh bien, ils ne fonctionneront que s'il existe un plugin Cordova prenant en charge ce que l'équipe essaie de réaliser. Cela signifie l'une des deux choses suivantes : soit l'équipe le crée elle-même, soit un plugin tiers approprié devra être trouvé pour faire le travail. Malheureusement, le plus souvent, la deuxième option n'existe pas. Par conséquent, il faut un temps de développement supplémentaire pour créer les plugins personnalisés, suivi d'un effort de support de construction - au fil du temps - pour gérer la bibliothèque croissante de plugins Cordova requis par l'application. Bien sûr, lorsque des mises à jour de Cordova se produisent, il est fort probable que ces plugins devront également être mis à jour.

Décalage de la prise en charge du système d'exploitation . Le problème de composant de pont en cascade / plug-in Cordova mentionné précédemment est encore exacerbé lorsque le système d'exploitation modifie les fonctionnalités de base. Une fois que Cordova, PhoneGap et Ionic ont été mis à jour pour prendre en charge les modifications, il est possible que les plugins personnalisés et les composants de pont doivent également être mis à jour. Quel que soit l'ordre de grandeur que ce travail nécessiterait, il en résulte un temps supplémentaire pendant lequel l'application ne prend pas en charge les utilisateurs finaux qui ont mis à jour vers le nouveau système d'exploitation. Ceci, bien sûr, est le pire des scénarios dans lequel Apple ou Google effectuent des modifications cassantes et non rétrocompatibles, ce qui n'arrive jamais… n'est-ce pas ? En général, tout framework intermédiaire qui est hors du contrôle du développeur et qui doit d'abord être mis à jour ne sert qu'à retarder le processus. Enfin, s'appuyer sur un cadre intermédiaire peut être un casse-tête pour les chefs de projet, car le calendrier de ces cadres est tellement inconnu.

Applications non hybrides

Les applications non hybrides commencent leur vie comme leurs homologues hybrides - une couche d'interface utilisateur conçue dans un langage de plate-forme non natif : React Native utilise HTML/CSS soutenu par JavaScript ou Xamarin, qui est basé sur C# en raison de ses racines .NET.

Cependant, c'est là que s'arrête la similitude. Les applications non hybrides se compilent en code natif et rendent l'application à l'aide de composants natifs de la plate-forme au lieu d'effectuer un rendu via une vue Web. Il en résulte un cadre WODE qui, du moins en surface, offre le meilleur des deux mondes.

Comme indiqué précédemment, choisir d'utiliser JavaScript ne doit pas être une décision prise à la légère, et cela pourrait être un facteur décisif pour une équipe de développement qui ne souhaite pas apprendre ou n'a aucun intérêt à utiliser JavaScript.

Avantages

Plus performant que les hybrides . Comme on pouvait s'y attendre, les applications non hybrides ont intrinsèquement des performances supérieures à celles des applications hybrides en raison de leur capacité à rendre l'application à l'aide de composants d'interface utilisateur natifs (boutons, vues, gestionnaires de mise en page, etc.) au lieu de s'appuyer sur une vue Web intégrée. Bien sûr, les développeurs sont toujours libres d'écrire une application qui fonctionne de manière remarquable ou horrible. L'avantage des applications non hybrides est simplement qu'elles ont une base de performances plus élevée par rapport aux applications hybrides similaires.

Equipe de développement minimale . Semblables aux frameworks hybrides, les non-hybrides permettent à une petite équipe de développement, et en particulier à une équipe dont la base de connaissances principale est le développement Web, de produire rapidement des applications simples sur plusieurs plates-formes. Cela permet aux chefs de projet de garder leur équipe petite et d'empêcher l'équipe d'apprendre les langages natifs et les frameworks pour plusieurs plates-formes.

Cycle de développement plus rapide . En plus d'une équipe plus petite, les frameworks non hybrides permettent un cycle de développement plus rapide lors du déploiement sur plusieurs plates-formes, car une seule couche de vue doit être conçue.

Itérations plus rapides (React) . Le framework React fournit une fonctionnalité puissante qui permet de restituer en temps réel les modifications apportées à l'application : pas besoin de recompiler, reconstruire, etc. De ce fait, l'émulateur React est un outil de développement incroyablement puissant qui réduit considérablement la durée de chaque implémentation. cycle.

Les inconvénients

Coûteux à personnaliser . Tout comme son homologue hybride, lorsque les applications non hybrides nécessitent l'amélioration de l'UX en concevant des interfaces utilisateur personnalisées pour chaque plate-forme, il en résulte des composants d'interface utilisateur complexes et uniques qui peuvent être coûteux à créer et difficiles à maintenir dans le temps. Cela signifie également écrire des composants de pont personnalisés pour combler les lacunes dans la prise en charge des éléments natifs du framework. Comme pour les hybrides, ce coût diminue l'avantage d'un cycle de conception rapide et peu coûteux, mais contrairement aux applications hybrides, les composants de pont sont écrits pour chaque plate-forme souhaitée dans leur langue maternelle . Cela signifie qu'au lieu que les applications non hybrides soient une alternative flexible à une équipe principalement composée de développeurs Web, les équipes qui choisissent la voie non hybride doivent apprendre non seulement le langage particulier du framework (par exemple, JSX ou C #) mais également le langage natif de chaque plate-forme (Java, Obj-C ou Swift).

Dépendances tierces . Cette limitation prend deux formes différentes. Dans le cas de React Native, cela prend la forme de nombreuses dépendances, soit environ 650. Le résultat est qu'il y a de très fortes chances à un moment donné qu'une ou plusieurs de ces dépendances soient obsolètes. Cela signifie également qu'en cas de changement important au niveau du système d'exploitation, il est fort probable que la plupart ou la totalité de ces dépendances devront être mises à jour. La grâce salvatrice potentielle est que Facebook utilise React, donc on aura le gorille de 300 lb dans son coin.

Dans le cas de Xamarin, le problème de dépendance à des tiers est simplement qu'il est extrêmement difficile de les intégrer en premier lieu. Xamarin est conscient de ce problème et fournit un outil utilitaire appelé Sharpie. Le but de l'outil est d'aider à une partie de l'intégration, mais malheureusement, Sharpie tente souvent de compiler et de lier des ressources incorrectes, ce qui oblige le développeur à entreprendre la tâche fastidieuse de modifier manuellement les paramètres de compilation de bas niveau afin de terminer avec succès l'intégration.

Décalage de la prise en charge du système d'exploitation . Les applications non hybrides sont confrontées au même problème que les applications hybrides. Tout framework intermédiaire qui est hors du contrôle du développeur et qui doit d'abord être mis à jour ne sert qu'à retarder le processus de mise à jour de son application pour prendre en charge les utilisateurs de pointe. De plus, comme indiqué précédemment, s'appuyer sur un cadre intermédiaire peut être un casse-tête pour les chefs de projet à planifier, car le calendrier de ces cadres est tellement inconnu.

Accompagnement long terme (React Native) . Ce problème est spécifique à React Native et concerne le fait étrange qu'à ce jour, Facebook ne s'est pas engagé dans un plan de support à long terme pour son framework. On peut dire qu'il s'agit d'un faible risque puisque l'entreprise utilise son propre framework pour ses applications mobiles, mais cela vaut la peine pour tout chef de projet de réfléchir aux raisons pour lesquelles Facebook a refusé de commenter le sujet.

Choisir la bonne approche

Lorsque le coût n'est pas une considération primordiale, la figure 2 montre que l'écriture d'applications natives est presque toujours le meilleur choix lorsqu'il s'agit de tirer parti de la composition de l'équipe de développement par rapport aux exigences de l'application. Lorsqu'il y a moins d'ingénieurs de développement que le nombre de plates-formes souhaitées, cela devient un peu plus intéressant. Dans ce cas, utiliser React est le bon choix si l'équipe est soumise à un calendrier de publication très serré ; sinon, devenir natif est toujours la meilleure option.

Lorsque l'équipe est principalement une équipe de développement Web et qu'une UX personnalisée est requise, il est préférable que certains membres de l'équipe changent de chapeau ou ajoutent des membres de l'équipe afin de rendre ses applications natives. Il n'y a vraiment pas d'option de framework faisable et maintenable si une application nécessite des éléments personnalisés, ce que font de nombreuses applications.

Cependant, si une UX personnalisée n'est pas requise, alors, selon le calendrier de publication, il peut être préférable d'opter pour Ionic ou React. Si votre équipe n'a pas le temps d'apprendre JSX, alors Ionic est le bon choix. Sinon, il vaut mieux choisir React car il nécessite déjà de nombreuses dépendances tierces, et en ajouter d'autres n'aura pas d'impact sur son cycle de développement.

Une fois que le coût du projet est une préoccupation majeure, généralement, la composition de l'équipe existante devient moins prioritaire puisque la première étape serait de mettre en place l'équipe appropriée pour exécuter le plan de projet pour le coût projeté. Comme le montre la figure 3 , les applications natives ont un coût de départ plus élevé que leurs homologues WODE, mais également un UX potentiel plus élevé. De plus, les applications WODE seront toujours limitées dans leur UX, quel que soit le montant d'argent et de ressources appliqué au projet.

J'espère que cet article a mis en lumière les avantages et les inconvénients de diverses voies de développement mobile, ainsi que aidé à peser la composition de l'équipe par rapport aux exigences de l'application et au coût du projet. Son message n'était pas de transmettre que les frameworks WODE sont inférieurs et ne devraient jamais être recherchés, mais plutôt que même s'il existe des cas d'utilisation valables pour ne pas devenir natifs, il faut bien comprendre les ramifications de le faire.