React Native (ou pas)

Dans le monde du développement mobile qui ne veut pas suivre Apple et Google, React Native est la star du moment. Mais à quel prix ?

[ MAJ du 17 octobre 2017 ]

Suite à plusieurs sollicitations, j’ai ajouté quelques précisions concernant la sécurité.

Historique des rebelles du développement mobile

Quand les apps mobiles Apple et Google sont arrivées sur le marché, en 2008, deux profils étaient prêts à s’aventurer sur le marché.

2 profils pour un nouveau marché

Les développeurs qui faisaient du développement bas niveau, de l’embarqué et/ou du mobile (Java ME, Symbian, Qt Embedded) : ceux-ci ont appris de nouveaux langages (plutôt facile) et surtout ont du apprendre de nouvelles API. La nouveauté était également le soucis de l’expérience utilisateur. Techniquement plus simple, mais plus complexe en matière d’expérience utilisateur.

Les développeurs qui faisaient du haut niveau, plutôt orienté web, étaient habitués à concevoir des interfaces. Par contre, ils n’étaient pas habitués à suivre des guidelines. Ni respecter les API système et encore moins coder en bas niveau. Le gap est plus important.

Cependant, les développeurs web étant plutôt facile à trouver, il a bien fallu s’adapter. Malgré les alertes des constructeurs, de nombreux outils se sont développés.

L’émergence des solutions hybrides

Plusieurs solutions hybrides sont arrivées sur le marché. La plus populaire étant PhoneGap (Cordova).

L’idée est simple : on conçoit une application web et on l’intègre dans une vue web.

C’est facile à vendre. Ça ne coûte pas cher (sur le papier). Et surtout, ça évite aux développeurs web de mettre à jour leurs compétences.

Oui, mais…

Rapidement, les choses se sont compliquées. Il n’y avait aucune cohérence au niveau de l’interface, donc on a conçu des frameworks CSS et Javascript qui imitaient les interfaces natives. On a imaginer plein d’astuces.

Ensuite, on a eu des problèmes avec l’intégration des fonctionnalités natives : l’accès à l’appareil photo, aux systèmes d’identifications (Touch ID) et bien d’autres.

On a donc inventé les plugins ! En gros, on conçoit du code natif qui est appelé depuis le code de la vue web. Ça fait le boulot. À court terme, c’est génial.

Seulement, ceci a créé une cascade de chaîne de dépendance entre les composants. Chacun a essayé de concevoir son outil de gestion de dépendances.

Puis, les développeurs ont abandonné leurs plugins. Il a donc fallu trouver des alternatives.

Sans parler des performances déplorables et des gros soucis de sécurité et d’incompatibilité.

En gros, la solution pour rendre les choses simples est devenue incroyablement complexe à gérer et à maintenir. 😭

Et le miracle React Native s’accomplit ! (ou pas)

Imaginez : la simplicité technique du web associée à la performance du natif. Un véritable petit miracle.

Évidemment, la réalité n’est pas si rose.

Un moteur Javascript pour piloter du natif

En gros, React Native s’appuie sur un moteur Javascript. Comme ça, les développeurs web ne sont pas perturbés. Surtout s’ils utilisent déjà le framework React en version web.

Là-dessus, il suffit d’interagir avec des composants génériques. C’est comme du React mais avec du natif plutôt que du HTML5 / CSS.

En plus, on peut profiter du rechargement du code à la volée.

La seule différence avec l’hybride

Le rendu est natif. Et on peut interagir avec du natif. Ce qui éloigne l’un des défauts majeurs de l’hybride : les performances et l’intégration au système.

Est-ce que cela efface tous les défauts pour autant ? Pas si sûr.

Une connaissance du natif toujours nécessaire

Dès que l’on va commencer à aller vers un véritable projet mobile, on va devoir commencer à avoir des compétences sur chaque plateforme.

Par défaut, les données stockées par React ne sont pas sécurisées. Il faut donc les sécuriser.

Les mécanismes liés à la sécurité doivent être connus de manière générale.

Dès lors que l’on voudra interagir avec Apple Watch ou Android Wear, il faudra connaître les mécaniques spécifiques du système.

Si l’on souhaite créer des extensions (partage, ouverture de fichiers, assistants vocaux, widgets et autres), il faut également avoir une véritable connaissance du natif.

Dès que l’on voudra exploiter pleinement les UI de l’OS, il faudra parfaitement connaître l’OS. Et donc les API natives.

Et nous ne parlons pas encore des technologies en émergences que sont la réalité augmentée et surtout le Machine Learning.

En clair, dès que l’on rentre dans un véritable projet mobile, il faut connaître le natif.

La sécurité en difficulté

Par défaut, le système React n’est pas sécurisé. D’autant que c’est du Javascript qui, même compilé, reste accessible “en clair” dans l’app.

Sauf si on commence à aller plus loin. Mais les développeurs web ont rarement l’habitude de s’occuper de telles contraintes : ce n’est pas leur métier.

[ MAJ du 17 octobre 2017 ]

Précisément, un développeur web pourrait se sentir protégé par la sécurité reconnue du natif.

Je vais prendre l’exemple de iOS. Notre développeur va stocker les URL d’API, les différents chemins à appeler. Et il va très probablement laisser les clés d’API dans le code, comme dans la majorité des cas.

Faites l’expérience vous-même. Construisez le “AwesomeProject” de React. Ajoutez une clé “cachée” dans App.js. Et une URL. Quelque-chose de réaliste.

Compilez l’application dans Xcode. Exportez-là pour l’App Store, de sorte à protéger le code.

Il en ressortira un fichier IPA. Renommez-le en ZIP. Dézippez. Allez dans “Payload/AwesomeProject” du répertoire cible. Clique droit : afficher le contenu du paquet. Ouvrez “main.jsbundle” dans un éditeur de texte. Reformattez le code pour plus de lisibilité. Et vous retrouverez l’URL saisie et la clé de sécurité pas très loin.

Voilà. 😞

Dès lors, on expose par défaut son application à des failles de sécurité. Alors que le natif permet automatiquement de rendre le code illisible. D’autant que sur iOS il est à la fois compilé et chiffré.

Que ce soit sur iOS ou Android, les options par défaut du natif sont sécurisées. Du côté de React, c’est quasiment l’opposé.

Il ne s’agit pas de dire que React n’est pas sécurisé. Mais ce n’est pas orienté pour la sécurité par défaut. Cela nécessite un gros travail complémentaire. De construction et de maintenance.

L’éternelle cascade de dépendances

Construire une app React signifie faire appel à de multiples plugins, réalisés par de multiples auteurs, avec de multiples versions et de multiples niveaux de compatibilité.

Sauf, évidemment, si on limite les dépendances. Mais ce n’est pas le choix par défaut. Généralement, on utilise les plugins pour pallier le manque de connaissance du mobile.

Pour la version 1, ça fonctionne toujours. Et c’est génial. Ça commence à se gâter à la première mise à jour. Et, au fur et à mesure, ça devient de plus en plus compliqué à gérer. On applique soi-même des patchs douteux. On ne sait plus ce qui est patché en “home made” ou non.

On s’éloigne complètement du sujet initial, qui est la construction d’une app, pour s’enliser dans la gestion des versions et des dépendances.

React Native peut être un bon choix pour…

La réalisation d’un POC (Proof Of Concept)

Un POC permet de valider un marché en premier lieu.

La sécurité n’a aucune incidence. Ce type de projet n’a pas vocation à être maintenu.

Faire un POC “vite fait” en React Native permet de valider un concept qui sera approfondi ensuite avec les technologies appropriées.

Une équipe bien formée sur le natif

Une équipe bien formée sur le natif pourra profiter de React Native pour sa capacité à charger du code à la volée.

Du fait de sa connaissance du mobile, l’équipe saura aller dans la bonne direction sans emprunter des chemins hasardeux.

React Native est à éviter pour…

Une équipe novice en développement natif

Ce serait reproduire l’erreur de l’hybride. Le projet deviendrait vite impossible à maintenir et les coûts exploseraient.

Pour faire du mobile, il faut une équipe mobile. Sinon, on fait du web mobile.

Une équipe novice en développement React

Le développement React est une approche particulière du Javascript. C’est déjà particulier sur du web. Alors avec du mobile, c’est un mélange des genres particuliers.

Si l’équipe est déjà à même de faire du natif, autant rester sur cette technologie. Après tout, c’est la technologie recommandée par Apple et Google, qui connaissent mieux que quiconque le système et les SDK qu’elles ont conçu.

Une équipe novice en développement mobile et React

Arriver sur du Javascript sauce React, rencontrer des problèmes qui nécessitent de faire appel à du Swift / Objective-C ou Kotlin / Java : c’est assurément atomique !

À quoi bon se compliquer la tâche ?

Objectivement, React fait intervenir au moins 3 technologies :

• Javascript
• la surcouche React et son SDK
• la technologie native. (et son langage)

Il est tout de même plus simple d’apprendre :

• le langage (Kotlin, Swift)
• le SDK. (Android, iOS)

D’autant que Javascript reste globalement un langage plus verbeux que Kotlin et Swift. Ces deux derniers ayant des syntaxes très proches.

Plutôt que de chercher des excuses, des prétextes et des outils pour ne pas vous lancer, tentez l’aventure.

Une fois lancé, ce n’est pas si effrayant. 🙂

S’accrocher au connu, c’est rester prisonnier de l’ignorance.

- Yvon Rivard