Développement d'application : le cross-platform avec React Native

Développer en natif ou cross-platform ?

Depuis que les smartphones sont smartphones, les développeurs d'applications doivent créer deux versions de leur projet : une pour Android et une pour iOS. Face à eux, deux stratégies sont possibles : développement en parallèle (ce qui nécessite deux équipes de développement) ou en série (ce qui nécessite deux fois plus de temps de développement). Cela implique aussi deux codebases et le risque non négligeable de divergence entre les deux projets.

Le défi est de taille pour toutes les startups qui se veulent agile, lean ou autre; dont le produit se définit au fil de l'eau, et où il faut être capable de sortir rapidement de nouvelles fonctionnalités. Développer deux applications va complètement à l'encontre de cette ambition. Nous pourrions bien en faire une seule, certes, mais nos utilisateurs sont des élèves de classes de l'enseignement supérieur dans lesquelles tout espoir de n'avoir que des étudiants sur iOS ou que sur Android est vain.

L’objectif de Brother Tongue ?

Chez Brother Tongue, nous repensons l'apprentissage des langues dans un monde de plus en plus mobile. Nous cherchons à connecter entre eux les étudiants pour qu'ils puissent apprendre ensemble. Nous leur fournissons un outil qui offre un contact quotidien avec la langue et qui s'appuie sur deux piliers : celui de la didactique des langues et celui de l'intelligence artificielle.

Au printemps de notre projet, et de l'année 2017, nous étions un chatbot sur Facebook Messenger. Nous le soumettions alors à l'épreuve de l'utilisateur. Le cadre du chatbot était trop étriqué pour que l'apprenant puisse s'épanouir totalement.  Le verdict est sans appel : il nous faut pivoter et créer une application propre ! Nous pourrions consacrer tout une colonne sur le sujet mais passons. Nous repartons donc de zéro. Nous sommes en juin 2017 et avons deux développeurs à temps plein dans l'équipe, avec certes une dizaine d'années d'expérience industrielle, qui plus est chez Google, mais sur des projets de backends et data science, bien loin de l'univers des applications. Au fond nous n'avons pas le choix, il nous faut parier sur le cross-platform, qui a encore un peu mauvaise presse… mais qui a le mérite de pallier à notre problème de ressources internes et d'agilité.

Nous pivotons donc vers une application mobile, et avant même la première ligne de code, il nous en fallait déjà deux, qui plus est dans deux langages et technologies bien différentes pour lesquelles nous n'avions aucune expérience (et pourtant les langages, on adore ça !). L'heure des "Hello Worlds" était de retour.

Quels frameworks ?

Ces framework sont nombreux et promettent tous le "code unique, plateformes multiples". Pour ce faire, en général, ils opèrent en encapsulant l'application dans une webview qui ainsi peut tourner en natif sur chacune des plateformes. Mais bien souvent, l'utilisateur ne s'y trompe pas, l'expérience n'est pas la même, et tôt ou tard, il va falloir réécrire le tout en natif. Dans le paysage virtuel des frameworks de développement cross-platform, deux acteurs semblaient sortir du lot : Ionic et React-native, qui rejouent sur mobile la bataille entre les deux géants californiens Google et Facebook.

Ionic se base sur Angular, le fameux framework javascript de Google pour les applications web. Chez Brother Tongue, Angular ça nous parle, puisque notre backoffice était déjà en Angularjs. Mais comme on aime les défis, a choisi l'autre candidat. Ionic implémente la technique classique de l'hybride via webview, et s'appuie sur d'autres framework tout à fait respectables comme Cordova et Phonegap, pour au final aboutir à du HTML et du CSS. Le mieux pour se faire une idée c'est encore de tester. On l'a fait, et le résultat était plutôt satisfaisant.

React-Native se base sur un paradigme différent, élégant et sans doute moins évident. Le framework est développé par Facebook, qui développe également ReactJS pour les applications web. Une application React-Native ressemble d'ailleurs beaucoup à une web app ReactJS. La différence principale réside dans l'introduction d'éléments spécifiques tels que <View> , <Button> , etc. qui viennent se substituer aux balises HTML habituelles <div> , <a> , etc. L'application est compilée pour Android et pour iOS de sorte que ces éléments sont affichés par des composants natifs. C'est comme si vous aviez écrit directement vos composants en Swift (iOS) ou en Java (Android). 

Comparaison quantitative

Dans une startup, on ne peut pas tergiverser longtemps, bien qu'on puisse regretter longtemps certains choix. L'argument de coût élimine le développement natif. Entre Ionic et React-Native, on apprécie l'élégance de React-Native, mais quand on choisit un langage ou un framework, on ne peut pas se baser uniquement sur un critère d'élégance. L'adhésion de la communauté et sa dynamique sont plus important, puisque c'est la communauté qui fera grandir le projet et qui assurera sa pérennité.

Commençons par les applications écrites dans les deux framework. Cela nous donnera une idée des perspectives. Côté React-Native, premier bon point pour Facebook qui utilise son propre projet pour le développement de ses apps telles qu’Instagram. On compte également des applications très populaires comme Airbnb, Skype, Baidu, UberEATS etc. Côté Ionic, pour commencer Google ne semble pas miser dessus pour ses applications, du moins pas à notre connaissance (et on était de la maison). Ensuite la liste des projets les plus importants semble indiquer que Ionic n'est aujourd'hui pas utilisé pour des projets aussi conséquents que les figures de proue de React-Native.

Pour aller plus loin dans la comparaison, nous nous intéressons à l'activité des deux projets sur github. Cela donne une idée de la santé du projet ainsi que de sa maturité. Tout d'abord, pour Ionic, on constate un certain déclin du nombre de commits.

Nombre de commits sur le projet ionic sur github (source: github)

Côté React-Native, le nombre de commits est plus stable.

Nombre de commits sur le projet React-Native sur github (source: github)

Attention toutefois à ne pas tirer de conclusion hâtive sur le déclin potentiel de Ionic. Il faut également prendre en compte que Ionic est un framework plus ancien et qu'il est assez naturel de voir ces courbes décliner avec le temps. Cependant, en regardant aussi les nombres absolus, on se rend compte que React-Native est plus actif que Ionic ne l'a jamais été… Encore un point pour React-Native donc 2-0 à la mi-temps ! Du côté de la côte de popularité, le point revient encore à React-Native, avec deux fois plus de stars en 3 ans que Ionic en 5 ans :

Github statistiques globales (source: NPM trends)

De manière générale, les indicateurs quantitatifs sur le code même des framework présentent une croissance plus soutenue de React-Native. Cette croissance est confirmée par le nombre de npm installs au cours de ces deux dernières années

npm installs de React-Native et Ionic-Angular en 2017 (source: NPM Trends)

Malheureusement, nous n'avons pas trouvé de données chiffrées quant au nombre d'applications Ionic et React-Native présentent sur le Play store et l'App store. Mais une dernière comparaison scelle à ce jour l'issue du combat. Le nombre de recherche sur Google constitue un bon indicateur de la santé et de l'attractivité du projet. On constate ainsi un intérêt croissant des utilisateurs pour React-Native par rapport au développement natif sur le moteur de recherche.

Interest in React-Native as measured by Google (source: Google Trends)

Le cross-platform est-il agnostique ?

Voilà donc 8 mois que nous utilisons React-Native. Le code a été écrit principalement par un seul ingénieur. Cela représente environ 15k lignes de code. Nous avons une app sur l'App Store et sur le PlayStore, mises à jour de façon régulière.

On nous demande souvent combien de fois on doit écrire "if (platform == iOS)". C'est une question pertinente car si on écrit finalement deux applications dans un seul codebase ce n’est plus du cross-platform. Aujourd'hui, sur 15k lignes de code, nous avons moins de 15 occurrences. Soit environ 1 une occurrence pour 1000 lignes de code.

En y regardant de plus près, on se rend compte qu'il s'agit soit de question de style (taille de la fonte, position de certains éléments, etc) soit de notifications. Par exemple, l’iPhone X présente des particularités d'écran qui nous oblige à un traitement spécifique. De manière générale, il est très satisfaisant que la grande majorité des librairies et frameworks s'intègrent les yeux fermés.

Conclusion 

React-Native apparaît à ce jour comme une bonne solution pour se lancer dans un développement cross platform. Le framework a atteint une certaine maturité, gagne en popularité, sa communauté s'accroît et des projets ambitieux l'adoptent. Pour l'utilisateur le rendu est natif et pour le développeur la philosophie sous-jacente est élégante (notamment la séparation des fonctionnalités via Sagas et Redux) et le code lisible.

Le développement d'une application mobile est une aventure que chaque startup aura sans doute un jour à débuter dans un monde où le smartphone est roi. Choisir les briques technologiques pour le développement produit peut s'avérer crucial pour la santé de l'entreprise : coût de développement, de maintenance, recrutement de profils techniques d'une part et expérience utilisateur d'autre part. Ces choix ne sont pas seulement motivés par une préférence personnelle, mais par un mouvement général de toute une industrie numérique, dont la direction collective ne tardera pas à sélectionner certains projets au profit d'autres pourtant prometteurs.

Nous n'avons pas de boule de cristal. Mais il faut bien choisir et en s'appuyant sur une étude pratique et théorique, chez Brother Tongue, nous avons choisi de suivre le mouvement React-Native et à ce jour nous sommes très satisfaits de ce choix.

Olivier Teboul, co-fondateur et CTO de Brother Tongue

Frederico Quintao, Head of Product Development de Brother Tongue