Développer une application : en natif ou en HTML5 ?

La question est de plus en plus fréquente pour les développeurs et pour les entreprises. D’un coté il y a l’efficacité de l’adaptation à la plateforme, de l’autre la possibilité de supporter plusieurs plateformes mobiles. Quelle solution aborder à un coût raisonnable ? Web ? Natif ? Hybride ? Une réponse rapide conduirait à dire web compte tenu des parts de marché de chaque plateforme. C’est loin d’être aussi simple.

Développer en natif permet de s’intégrer au mieux à la plateforme et de supporter le maximum de ses fonctionnalités. La contrepartie est souvent de devoir multiplier les ressources de développement par plateforme. C’est donc vite cher puisque le code n’est pas ré-utilisable directement de l’une vers l’autre plateforme. Si en plus vous ajouter la fragmentation interne à la plateforme, c’est vite compliqué tant en temps de développement qu’en maintenance. Par contre, vous avez accès aux toutes dernières fonctionnalités de la plateforme (NFC, MDM, …). Coté back-ends, il est possible de se connecter à toute interface qu’elle soit standard ou non.

Développer en HTML 5 est séduisant. La norme produite par le W3C aide à uniformiser les accès aux fonctionnalités du mobile. Le rendu se fait à travers le navigateur web est toutefois très disparate d’une plateforme à l’autre voire même d’un téléphone à l’autre. De plus le navigateurs sont en retard sur l’implémentation de la norme (elle même attendue finale en 2014) ou proposent des fonctionnalités propriétaires équivalentes. Ajoute à cela des performances brutes du navigateurs non égales d’une plateforme à l’autre. Vous vous retrouvez vite à devoir élaguer des fonctionnalités vers le plus petit commun dénominateur des plateformes ciblée. Enfin, le HTML5 pur ne permet pas de soumission sur les market places (Google Play, Apple App Store, …). Les utilisateurs attendent les applications à ces endroit. En plus de cela, développer en HTML5 ne dédouane pas d’adapter l’ergonomie à la plateforme cible. Il n’est pas possible d’adresser des utilisateurs Android avec un design iPhone ou inversement. Coté back-end, il faut dialoguer en JSON. C’est simple pour beaucoup de CMS mais peut être complexe avec les solution très typées sur un business particulier.

Quelles solutions ?

Les frameworks et les applications hybrides sont une solution intéressante. Il y en a un certain nombre comme PhoneGap, Titanium, Hawk, etc …

PhoneGap est simple et petit. C’est une boite vide qui fourni au développeur une interface Javascript vers le système de la plateforme. La boite n’attend que le contenu HTML5 (UI et logique) pour former un package équivalent au natif (un apk dans le cas d’Android). C’est là une force importante de PhoneGap à travers les 7 plateformes supportées. Avec de faibles variations, vous supportez beaucoup. Mais de la même manière que le HTML5, une application Phonegap repose sur le navigateur de la plateforme. Vous retrouvez alors les mêmes défauts. Dès que vous souhaitez des fonctions non supportées par PhoneGap, vous devez passer par le développement d’un plugin sur le SDK natif…. Retour arrière …

Grosso modo, PhoneGap ne sert « qu’à » accéder aux fonctionnalités système et à fournir une application accessible via les marketplaces.

Titanium propose une autre approche pour réduire la dépendance au navigateur. Les concepteurs fournissent un interpréteur de commandes Javascript qui s’interface directement avec les composants natifs du téléphone. C’est donc plus efficace en termes de rendu et de performances. Les inconvénients sont alors ceux de frameworks plus lourds encore tel Flash ou Silverlight. Le javascript utilisé est très orienté par plateforme et le support d’une nouvelle fonctionnalité est sujet à l’ajout par les concepteurs de la plateforme. Quand à supporter une nouvelle plateforme c’est difficile de l’aveu même des concepteurs de Titanium. Ils supportent iOS et Android.

Titanium uniformise les compétences requises sur iOS et Android mais s’éloigne de la mutualisation de code.

Chaque solution a donc ses avantages et ses inconvénients. Pour réduire l’écart entre toutes ces solutions, Mootwin, startup française, a présenté  lors de la conférence Mosquito une solution intéressante. Plutôt que de fournir une solution de développement « uniformisante » aux développeurs, ils proposent des fonctionnalités pré-codées pour les SDK natifs, PhoneGap et Titanium. Les fonctionnalités proposées permettent de gagner du temps sur le développement en évitant le codage des parties les plus rébarbatives et longues. En plus de cela, la société propose des features sympa comme le push temps réel depuis le serveur, la résistance aux conditions de réseaux pauvres ou très détériorées. Ils proposent aussi des modules fonctionnels complets (orientés business) qui nécessiteraient beaucoup de temps de développement et de test. Enfin, en utilisant leur serveur d’applications, il proposent de réduire le temps de développement de 70% pour le portage vers une nouvelle plateforme mobile.

Une façon intéressante d’améliorer fonctionnellement les applications et de faciliter la vie de développeurs… Quelle stratégie de développement d’application utilisez vous ?