Applications hybrides : avantages et fonctionnement

Il pourrait être facile de penser que pour deux plateformes mobiles distinctes (iOS et Android), les développements doivent se faire également dans deux environnements distincts. Apple et Google fournissent outils et langages pour le développement d'applications sur leur plateforme respective : c’est ce qu’on appelle le développement natif. L’emploi de ces technologies semble donc tout indiqué, mais même si cette réflexion semble la plus simple et la plus logique, elle n’est pas exclusive.

Développer le même projet plusieurs fois peut poser quelques problèmes. Le premier étant évidemment lié au temps de production du projet. Le temps de développement mais aussi le temps de recette, même s’ils ne sont pas multipliés par 2, sont considérablement augmentés.

Une façon de pallier cet écueil est ce que l’on appelle le développement hybride. Plutôt que de développer un projet distinct par plateforme, nous développons un seul projet dans une technologie tierce. Puis, un programme viendra transformer ce projet pour fonctionner comme une application sur chacune des plateformes.

La technologie tierce retenue est très souvent un langage web. Le principe “d'encapsulation“ est finalement une application native, embarquant un navigateur réduit à son plus simple appareil, qui permet d’afficher un site web. A la différence d’un site où le projet web serait hébergé, ici, les fichiers qui constituent le projet sont servis localement. Il n’y a donc pas besoin de prévoir un hébergement pour ce genre de projet.

Au-delà du gain évident du temps de développement/de recette et du coût induit par ces délais, il existe d’autres impacts positifs. Un seul projet à développer signifie que vous serez visible sur les stores au plus tôt. Quand votre projet sera prêt à évoluer, un seul développement sera nécessaire pour faire évoluer 2 applications !

Dans le cas où vous souhaiteriez voir votre charte graphique reportée, de votre site vers votre application, certaines passerelles sont possibles. Le code lié à l'interface graphique peut être mutualisé.

Faire le choix du développement dans un langage web à Webqam, agence de développement mobile, c’est l’assurance de profiter d’une expertise de plus de 15 ans dans le domaine. Le choix des langages, des outils et des process est maîtrisé. La totalité de notre équipe de production est capable de participer à un tel projet.

D’un point de vue technique, c’est en réalité l'emploi de plusieurs technologies qui s’articulent autour de votre projet.

En ce qui concerne le développement, un langage web est donc retenu. Dans le cas de Webqam, il s’agit de VueJS. Ce langage, orienté front, est extrêmement performant. Il offre des fonctionnalités permettant de produire simplement des applications complexes. Encore une fois, ce langage est le plus maîtrisé au sein de nos équipes de développement. La capitalisation de nos connaissances ainsi que notre esprit d’équipe sont largement mis à profit !

A ce langage de développement, nous venons adjoindre une autre technologie. Un framework nommé Ionic. Ce framework est très utile sur deux aspects majeurs. Tout d'abord, il fournit un ensemble de composants graphiques (boutons, menu, …). Ces composants prendront l’apparence des composants natifs selon la plateforme sur laquelle est exécutée l’application. Ainsi, vos utilisateurs retrouveront des interfaces graphiques et des comportements qui leur sont familiers.

D’autre part, Ionic propose un ensemble de passerelles, appelées plugins, permettant la communication avec les appareils de vos utilisateurs, comme une application native. Appareil photo, GPS, notifications…, toutes ces fonctionnalités seront accessibles malgré le fait que le projet est une “coquille” d’application, affichant un projet web.

En ce qui concerne la phase d’encapsulation, la technologie retenue s’appelle Capacitor. Cette technologie va, dans un premier temps, générer les projets d’applications vierges. Exactement comme nous le ferions en utilisant les outils dédiées aux applications natives. Nous nous retrouvons donc avec 3 projets : un projet web sur lequel nous allons travailler, un projet iOS et un projet Android. Le développement peut commencer.

Enfin, à partir du projet web compilé, Capacitor va injecter ce code dans les projets vierges, en faisant le lien avec les plugins pour donner accès au projet aux fonctionnalités natives des appareils.

A ce moment de la production, les projets mobiles sont exécutables sur des appareils et peuvent être déployés sur les stores.

Capacitor n’est pas la seule technologie permettant d’obtenir deux applications à partir d’un seul projet source. Une autre excellente alternative est React-Native. A la différence de Ionic, le langage retenu ici est React-Native. Ce langage ressemble dans sa syntaxe et ses fonctionnalités à son cousin React, dédié au développement web, mais avec un ensemble de composants graphiques différent.

La principale différence avec Ionic c’est que le projet, une fois compilé (=convertit en langage processeur pour un smartphone ou une tablette), peut être directement exécuté par le moteur de rendu de l’appareil. C'est-à-dire que l’application ne va pas simplement ressembler à une application native, elle aura été générée spécialement pour fonctionner sur un appareil mobile. Pour cet aspect, mais aussi pour le fait de ne pas utiliser de navigateur embarqué pour afficher des pages web, les performances seront globalement meilleures qu’avec un projet Ionic.

Un tel choix technologique ne peut se faire au détriment de certains aspects. Il est nécessaire de les avoir en tête au moment de choisir une technologie avant de se retrouver bloqué au moment d’envisager des évolutions.

L’initialisation d’un tel projet est légèrement plus complexe qu’un projet web ou un projet mobile natif. En effet, l’environnement de travail doit être configuré à la fois pour le développement web ET le développement natif. Cela pour pouvoir intervenir dans toutes les phases de développement du projet.

Malgré la quantité et la qualité des plugins disponibles pour donner accès aux fonctionnalités des appareils au projet, tous les accès ne sont pas garantis. Bien que dans l'immense majorité des cas, le développement hybride réponde à tous les besoins de vos projets, certaines fonctionnalités avancées ne seront pas accessibles. En particulier des fonctionnalités les plus récentes annoncées par Apple et par Google.

Il est primordial que nous discutions ensemble de comment vous imaginez votre projet afin que nous trouvions ensemble le meilleur compromis en termes d’implémentation.

Enfin, il est à noter que l’empilement de technologies : projet web, affiché dans un navigateur, d’une application, exécutée par l’OS peut être à l’origine d’une légère baisse de performances. Ces baisses se caractérisent par de légers ralentissements, des animations moins fluides etc. Bien que souvent négligeables, elles peuvent nuire à l’image de marque de votre produit.