Hybride VS Natif : le combat de l’année !

Hybride VS Natif : le combat de l’année !

Hybride VS Natif : le combat de l’année !

Lors de notre visite aux AppDays 2017, la question de l’hybride VS natif mobile flottait dans l’air ! Les différentes conférences et échanges entre développeurs et agences nous ont permis de faire enfin un point complet sur ce sujet, et de recenser les différentes technologies disponibles à l’heure actuelle.

PWA (Progressive Web App) 

Sorte d’application web-responsive conçue en « Single Page App » avec un look&feel proche du natif. Utilisable immédiatement sans installation, elle permet l’accès à certaines fonctions natives (photos, vidéos, push) et un fonctionnement possible en offline. De plus, en termes de déploiements, pas besoin de déposer « l’application » sur les stores. Cependant, les performances ne sont pas exceptionnelles, notamment avec le manque d’accès à de nombreuses fonctions natives et surtout, pas de fonctionnement pour l’instant sous Safari iOS !

 

Cordova, PhoneGap, Ionic et autres…

Ces outils permettent de générer des applications avec un socle natif basique, codées en JS/HTML, avec un rendu dans une webView. Le langage Javascript qui est particulièrement répandu (communauté de développeurs web conséquente) s’interface avec certaines fonctions natives mais comme les PWA, on retrouve des problèmes de performance et une forte dépendance aux mises à jour et aux évolutions de ces outils de compilation. Que faire si un bug se profil dans le framework ? De plus, il est nécessaire d’adapter spécifiquement l’UI suivant l’OS. Le code n’est donc pas totalement mutualisé.

 

Appcelerator (Titanium)

Ce kit de développement permet d’obtenir des applications codées également en JS/HTML mais converties en code natif et compilées pour chaque OS cible. On y retrouve les avantages des précédents outils (langage répandu, forte communauté) avec l’ajout non négligeable des performances du natif ! Hélas, ce framework semble de moins en moins maintenu (bugs, instabilités du code généré) et là encore, il est malgré tout nécessaire d’adapter spécifiquement l’UX/UI suivant l’OS.

 

Xamarin (Microsoft)

Ce framework permet de coder des applications mobiles en C# avec un binaire natif pour chaque OS cible. Le langage est mature et on conserve donc les performances du natif. Il est cependant difficile de trouver des développeurs expérimentés (plutôt orientés C# back-end). De plus, les tests/évaluations d’une équipe de développeurs d’une grosse société française ont mis en lumière une instabilité du framework et surtout un pourcentage de code pas si mutualisé que ça (forte dépendance UI), entrainant même l’abandon de cette solution pour leur projet.

 

React Native

Ce framework propose le codage d’application en React (Javascript) compilée en natif pour chaque OS cible. Créé par Facebook, la communauté React Web est large. On reste par contre toujours dépendant d’un framework « propriétaire » et Facebook informe très clairement les développeurs sur le fait que le code UI sera spécifique à chaque OS (« Learn once, write anywhere »). Par ailleurs, la prise en main reste complexe et il n’y pas d’interface pour construire l’UI.

 

Pour finir, passons rapidement sur 3 solutions plus « exotiques » :

 

Modules C++ : Un langage mature, exploitable dans les framework natifs (XCode et Android Studio) mais qui doit s’interfacer avec les langages natifs Java et Objective C et qui ne supporte pas l’UI.

J2ObjC : Un convertisseur Java Android vers Objective C qui permet de rester en natif mais quid de la qualité de la conversion (surtout que l’UI n’est justement pas convertie) ?

Go Mobile : Un langage (le Go) qui est également converti en Java et Objective C en mode natif mais un langage spécifique avec toujours une interrogation sur la qualité du code généré (UI non prise en charge).

 

En conclusion ? Si le choix d’un développement hybride peut être séduisant, il y a cependant 2 règles importantes qui conditionnent son utilisation (pour une optimisation du pourcentage des sources mutualisées) :

  • un code « métier » conséquent (algorithmes, traitement de données, etc….)
  • et surtout une part d’UX/UI inférieure à 50% du projet.

 

Dans tous les cas, l’hybride mobile n’est pas la solution « miracle » et on est loin de la promesse d’avoir un code totalement mutualisé et une division des coûts de développement par 2 ! La plupart des agences de dév mobile et clients finaux rencontrés aux AppDays ont d’ailleurs fait en grande majorité le choix du natif, au détriment des framework propriétaires hybrides.

Le choix de la raison ? Probablement… 😉

Pour vous aider dans votre prise de décision, nous avons réalisé un document qui liste les avantages et les inconvénients de chacune des solutions mentionnées ci-dessus. Vous pouvez télécharger le PDF en cliquant ici.