Là où l'heure est à la comparaison de React Native / Flutter vs Applications natives (Swift, Objective-c, Kotlin, Java), nous pensons plutôt que chacune de ces solutions est adaptée à un besoin spécifique. Débattre sans arrêt de "qui est le plus performant, qui est le meilleur, qui est le plus fort...", n'apporte généralement rien de pertinent. D'autant que le succès d'une techno est souvent liée à sa "hype".

Le choix d'une techno mobile devrait plutôt se faire après s'être posé quelques questions :

• Quelle expérience je veux proposer à mes utilisateurs ?
• Quelles sont les spécificités de mon application ?
• Quel est mon budget ?
• Quels est mon délai de réalisation souhaité ?
• Quelles sont mes capacités (homme, budget) de maintenabilité technique ?

‍

On peut citer l'exemple de Airbnb qui a commencé sur des applications hybrides. Ce choix technique devait probablement être celui qui répondait le mieux à leur stratégie à l'époque. Ils ont depuis évolué pour du code natif car leurs enjeux économiques et leur volume d'utilisateurs se sont grandement développés. Il est aussi important de noter que pour Airbnb l'application mobile est devenu une source de revenu majeur.

‍

A chacun ses avantages, et ses inconvénients

‍

1. Hybride

A. Bénéfices

1. Prise en main facilitée

Les frameworks hybrides disposent de nombreux atouts. Pour commencer, un langage universel aux 2 plateformes. React Native c'est du JavaScript, donc un langage web que déjà beaucoup de développeurs connaissent, ce qui facilitera le recrutement et l'onboarding. Par expérience, un développeur web ayant travaillé sur React mais qui n'a jamais fait de mobile n'aura pas trop de mal à s'adapter s'il doit travailler sur une app mobile en React Native. Pour Flutter, le Dart, a été créé par Google spécialement pour le développement d'applications mobiles. Il est (pour le moment) moins répandu que son confrère mais s'apprend assez facilement et est très intuitif.

2. Communauté hyper active

React Native et Flutter, étant en plein coeur de la hype actuellement, possèdent tous deux une très large communauté, ce qui représente un atout considérable dans le choix d'une techno. En effet, une des qualités d'un bon développeur est de savoir se débrouiller pour trouver des réponses aux problématiques qu'il rencontre. Pour se faire, on se dirige généralement vers la documentation technique officielle ou des sites comme StackOverflow ou sur Github.

3. (quasi) Pas de limite fonctionnelle et expérientielle

On pourrait croire que les frameworks hybrides limitent le champ des possibilités techniques, mais ce n'est pas tout à fait le cas. Ils reposent tous les deux sur du code natif et ouvrent la possibilité à la création d'un bridge, une couche intermédiaire entre le code natif et l'hybride qui permet d'interagir entre les deux. Grâce à ça on peut créer et/ou exploiter des modules natifs depuis du Javascript ou du Dart afin d'utiliser des fonctionnalités natives qui n'auraient pas pu être accessibles de prime abord comme l'appareil photo du smartphone, le Bluetooth ou la géolocalisation GPS etc...

De plus, je lis souvent qu'un inconvénient de l'hybride est qu'il ne gère pas l'offline (sans connexion internet). Or c'est faux. On peut tout à fait créer une application offline que ce soit en React Native ou Flutter.

4. Développements plus rapides = Coût moins élevé

Le fait d'avoir une seule codebase pour 2 applications distinctes réduira forcément le temps de développement et de maintenance d'une application. Chaque écran ne sera à intégrer qu'une seule fois. Chaque bug (si pas spécifique à un OS) ne sera à corriger qu'une seule fois. En termes d'ops, la compilation du binaire de l'application peut être généré sur les 2 plateformes à la fois. Le coût d'une application et de sa maintenance en seront donc moins coûteuses que sur du natif où 2 applications distinctes seront à développer par 2 équipes spécialisées sur chacun des langages (Swift vs Kotlin).

B. Limites

1. Performances graphiques limitées

Même si l'hybride possède beaucoup d'avantages, il ne correspond pas à certains besoins. Les jeux vidéos ou des applications avec de la 3D ou de l'AR seront moins performantes et plus difficilement réalisables que sur du natif.

2. Dépendance aux bibliothèques externes

C'est un point qui peut être vu comme une qualité ou un défaut. Les applications hybrides sont souvent dépendantes de bibliothèques externes afin de faciliter et accélérer son travail.

On pourrait noter comme exemple la création d'un bridge permettant d'accéder à l'appareil photo de son téléphone. C'est une fonctionnalité qui demanderait du temps à être développée "from scratch". La communauté étant très présente, plusieurs développeurs proposent des solutions open-source à ce genre de défis. On gagnera du temps à les intégrer, mais on deviendra également dépendant de cette bibliothèque et de son code. Si il n'est plus maintenu ou s'il présente des failles de sécurité, notre application sera également affecté.

Avant d'installer une bibliothèque, il faut se poser la question du temps et des avantages que ça prendrait de développer la fonctionnalité soi-même et des inconvénients que cela représente. Dans tous les cas, les dépendances d'un projet se doivent d'être méticuleusement choisies.

3. Rigueur de développement et tests obligatoire

Quand on développe en hybride, on rencontre de temps en temps des situations qui fonctionnent sur un OS, mais pas sur l'autre. Cela demande d'avoir une rigueur constante lors du développement et des tests de son application afin de s'assurer du bon comportement sur les 2 plateformes.

‍

2. Natif

A. Bénéfices

1. App 100% optimisée aux systèmes d'exploitations

Avoir une seule codebase par OS, c'est concentrer ses efforts sur une chose à la fois.

Contrairement à l'hybride, les applications natives seront pensées exclusivement pour l'OS concerné, ce qui pourra améliorer le rendu final et tirer le meilleur du système d'exploitation dès la conception de l'application.

2. Meilleures performances globales

Comme on s'en doute concernant le développement natif, il n'aura comme limite que les performances du device. Les apps ne seront pas surchargées par un framework convertissant du code, et seront donc plus légères et plus performantes (en fonction des features intégrées) qu'une app développée avec un framework hybride.

Les applications gourmandes en ressources graphiques, comme des jeux vidéos en 3D ou de la réalité augmenté préféreront par exemple souvent du code natif.

B. Limites

1. Développements plus longs = coûts plus élevé

Un des inconvénients du développement natif est que sa codebase sera spécifique à sa plateforme. Deux applications distinctes iOS et Android seront nécessaires pour pouvoir atteindre un maximum de clients. Le nombre de bugs potentiels sera également plus élevé car il ne concernera pas qu'une seule codebase. Les développements demanderont probablement plus de ressources ce qui influera sur le coût total de l'application.

2. Trouver des "experts"

Contrairement à l'hybride, la communauté native est moins en vogue. Les développeurs experts en la matière sont moins nombreux donc plus difficiles et plus chers à recruter pour les entreprises.
‍

Conclusion

Chez Dernier Cri, nos clients ont souvent un objectif identique : j'ai une idée de service, je veux réaliser l'application rapidement et à meilleur coût, valider son potentiel et la faire évoluer grâce aux revenus générés.

En synthèse, je veux le meilleur rapport qualité / prix d'une application qui m'accompagnera les 3 ou 4 prochaines années.

Pour ces raisons, le choix d'utiliser un framework hybride semble naturellement adapté :

Le développement de nouvelles applications mobiles innovantes via une solution hybride permet de réduire les risques et d'accélérer le TTM (Time To Market), tout en restant très compétitif en termes de performances et de fonctionnalités.

‍