Débat : Web Apps VS Natif

Lundi 5 septembre 2011 se tenait la Update Conf 2011 à Brighton, nous y étions ! Nous avons notamment assisté à une table ronde ("geek ninja battle" pour les jeunes) sur le thème "Web Apps VS natif" qui réunissait :

Matt Gemmel (Développeur iOS, auteur du fameux client Twitter) Jeremy Keith (Web developer) Seb Lee-Delisle (consultant) Martin Beeby (évangéliste Microsoft) Kevin Whinnery (évangéliste Titanium)

Débat mené par Aral Balkan organisateur de la Updateconf

Le sujet a déjà fait couler beaucoup d'encre, cette table ronde a été l'occasion de résumer les différences entre ces deux approches du développement mobile et de vulgariser des considérations complexes. Cet article propose une synthèse de ces discussions. On notera que ces discussions ne traitaient pas de l'aspect stratégie mobile mais d'une comparaison technique entre ces deux approches du développement mobile.

Mais avant tout deux définitions s'imposent :

Application native : Application conçue spécifiquement pour une plateforme en utilisant le SDK propre à celle ci. Web app : Application réalisée via un site Web optimisé pour mobile

Résumé de l'intervention sur les Web Apps mobile :

Le principal bénéfice d'une Web App est de créer une application "universelle" : l'application ainsi produite a la possibilité de s'exécuter sur n'importe quel device, aussi bien smartphones que feature phone. Un autre point à considérer est la durée de vie des applications : une application Web sera toujours accessible, par exemple les tous premiers sites Web sont toujours utilisables. En revanche une application native est liée à une plateforme et aux devices qui l'utilisent, sa durée de vie est donc au maximum celle de la plateforme, et souvent des problèmes de rétrocompatibilité limitent sa durée de vie à quelques années.

En se basant sur ce constat d'universalité et de durée de vie des applications, la discussion prenait parfois une tournure quasi idéologique : en effet réaliser une application native s'inscrit dans le "flow", et ne fait que passer. Tandis que produire une application Web permet de participer au "stock" et enrichit le Web pour les générations futures.

Pour revenir à des considérations plus pratiques il faut tenir compte des limitations actuelles de l'approche Web App. Les navigateurs des téléphones sont très hétérogènes et ont chacun une implémentation différente des standards du Web :

- Différences de capacités entre le navigateur d'un feature phone et celui d'un smartphone - Différence de comportement entre les navigateurs de différents smartphones pour la même fonctionnalité

Cette contrainte se heurte au fait que les applications mobiles sont devenues de plus en plus évoluées en terme d'interface. Une mauvaise pratique consiste à chercher à faire une Web App avec une interface reproduisant le comportement d'une application native : d'une part c'est techniquement complexe et on perd rapidement la compatibilité avec de nombreux navigateurs. Mais il faut également tenir compte du fait que chaque plateforme cherche à se différencier en proposant une ergonomie native différente. Dans ce contexte faire un site Web avec une ergonomie native pose deux problèmes :

- Si on essaye de reproduire l'ergonomie propre à chaque plateforme on recommence à faire des développements spécifiques à chaque plateforme - Si on reproduit le comportement d'une application iPhone sur chaque plateforme, le résultat est décevant pour les utilisateurs des autres plateformes.

La bonne pratique en terme d'interface pour les Web App consiste à reprendre les standards d'ergonomie du Web et d'adapter l'interface aux différents téléphones selon deux axes :

- Adapter l'interface à la taille de l'écran du téléphone/Smartphone - Adapter les fonctionnalités de l'application aux possibilités techniques du navigateur.

Ce dernier point peut s'avérer complexe, la recommandation pour qu'un site Web puisse offrir une expérience optimum sur chaque device consiste à faire du "progressive enhancement" :

Il s'agit de partir d'une approche orientée document (HTML sans JavaScript), bien gérée par tous les navigateurs, et qui assure un ensemble minimum de fonctionnalités quelque soit l'utilisateur qui consulte l'application. Puis aller vers une approche orientée interaction et comportement, en adaptant le site aux possibilités disponibles sur le navigateur qui consulte l'application.

Les intervenants mettaient également en garde contre le fait de faire du spécifique pour chaque navigateur : on retombe dans le même travers que de faire du spécifique pour des devices. A la place il est conseillé d'optimiser l'application pour des fonctionnalités : choisir une implémentation standard, et n'activer cette fonctionnalité que si le navigateur la supporte.

Il faut noter que si aujourd'hui il est possible de reproduire en Web la plupart des fonctions d'une application native (utilisation offline, stockage de donnés, GPS, etc.), certains points restent aujourd'hui impossibles, typiquement l'accès aux données du téléphone (annuaire, calendrier, etc.).

Notre avis : il faut également tenir compte du manque de maturité de l'HTML5. Aujourd'hui démarrer une application Web embarquant une base de donnée locale, GPS et utilisation offline avec synchronisation des données comporte une part importante de R&D. Ces fonctionnalités existent dans les applications natives depuis plusieurs années et sont aujourd'hui totalement maîtrisées.

Résumé des interventions sur le développement natif sur mobile:

Chaque plate-forme possède ses spécificités en terme d'interface et crée son identité notamment sur ces différences d'ergonomie. Les applications natives permettent de proposer une expérience totalement intégrée à la plate-forme et de tirer parti de ses spécificités : On a en effet accès non seulement aux données du téléphone (calendrier, contacts, etc.) mais on peut également proposer au sein de son application une ergonomie intégrée à celle du téléphone.

Un point qui est rapidement soulevé est la question de la "proximité" avec l'OS.

De part leur nature les applications natives n'ont aucune couche d'abstraction avec le téléphone, ce qui les rend mieux intégrées :

Cette expérience utilisateur plus proche du device peut s'avérer déterminante dans un environnement fortement concurrentiel : si sur chaque plateforme une Web App est en concurrence avec plusieurs applications natives qui proposent le même service mais avec une expérience spécifique, comment se démarquer ?

_Notre avis : Nous partageons cette analyse concernant l'importance de l'expérience utilisateur et nous pensons fortement à la citation de Phil Libin, CEO d'Evernote : "We could probably save 70% of our development budget by switching to a single, cross-platform client, but we would probably lose 80% of our users."

cf: http://techcrunch.com/2011/01/19/evernote-mac-app-store/

Néanmoins on remarque qu'il y avait le même débat avec la JVM 10 ans auparavant. La leçon retenue est que la "distance" avec l'OS n'est pas déterminante en soit, ce qu'il faut prendre en compte c'est ce que les technos Web permettent de faire._

Les intervenants reconnaissaient que développer et maintenir une version spécifique de l'application pour chaque plateforme est complexe lorsque l'on souhaite multiplier les OS ciblés. C'est dans ce dilemme entre le coût et la valeur que de nombreuses solutions hybrides ont vu le jour, tels que PhoneGap et Appcelerator. Nous publierons prochainement un article détaillant ces approches hybrides.

Autres considérations abordées :

Monétisation :

Le mode de distribution des applications natives via des "stores" a fait ses preuves en tant que solution rentable permettant de générer du profit. Les perspectives business attirent un nombre important de développeurs et d'entreprises à réaliser des projets pour ces plate-formes et pousse l'innovation.

N'est ce pas une faiblesse des Web Apps que d'être privées de store ? Comment faciliter la conversion sur une Web App et réaliser l'équivalent du "one click purchase" ?

Deux arguments ont été évoqués pour défendre le modèle de distribution des Web Apps :

- Effectivement sur le Web le taux de conversion est plus faible, mais cela peut être compensé par une base d'utilisateur plus grande et l'absence de frais d'intermédiaires (les stores prennent un pourcentage sur les achats allant jusqu'à 30%)

- On voit arriver des stores pour les Web Apps, via les navigateurs (Chrome se dirige déjà dans cette direction avec son Web Store)

Notre avis : les intervenants n'ont pas évoqué le fait que les stores servent aussi de vitrines pour les applications et facilitent la découverte du service.

Innovation :

Il est possible de faire de plus en plus de choses via les Web Apps, mais les possibilités offertes en natif progressent également, le gap technologique entre le natif et les Web Apps ne va-t'il pas perdurer ?

On a déjà rencontré cette même situation avec Flash et HTML : l'histoire montre qu'il y a un seuil minimum à atteindre pour que les technologies Web répondent à l'essentiel des besoins. Passé ce stade la valeur apportée par les améliorations de la plate-forme ne justifie plus les contraintes qu'elle implique. Aujourd'hui un grand nombre d'applications sur les stores pourraient déjà être faites en Web.

Conclusion :

Au travers des interventions on a eu un bon résumé de la situation actuelle du développement mobile et cela en 45min, on regrette néanmoins que le débat soit resté assez dogmatique et trop général. Le sujet n'y est probablement pas pour rien, "Natif VS Web Apps" : chercher à élire la meilleur approche dans l'absolue n'a pas beaucoup de sens. On aurait préféré partir de certains cas d'usage relativement cadrés pour illustrer les différentes approches et ce qu'elles impliquent.

Par exemple :

- Délivrer du contenu (blog, prise de note) - Apporter un service (service public de consultation, bourse en ligne)

D'autre part le débat technique entre l'approche native et web ne suffit pas pour faire un choix. Avant tout il faut définir une stratégie mobile plus globale et poser des questions telles que :

Pourquoi je veux faire du mobile ? (se démarquer de la concurrence par l'innovation ? Trouver de nouveaux business models ? ) A quelle population je m'adresse ? Quel est le positionnement de mon canal mobile par rapport à mon canal web ? Etc

Ce sont les réponses à ces questions ET une bonne connaissance des différences techniques entre web app et natif qui permettront de faire le bon choix.