Le débat sur les applications mobiles
Introduction
Les applications mobiles et HTML5 comptent parmi les technologies les plus populaires à l'heure actuelle, et il existe de nombreuses similitudes. Les applications Web s'exécutent dans des navigateurs mobiles et peuvent également être réempaquetées en tant qu'applications natives sur différentes plates-formes mobiles. Compte tenu de la large gamme de plates-formes à prendre en charge, combinée à la puissance des navigateurs mobiles, les développeurs se tournent vers HTML5 pour l'utiliser comme une solution permettant d'écrire une seule fois, d'en exécuter plusieurs. Mais est-ce vraiment viable ? Il existe tout de même de bonnes raisons d'adopter le mode natif et, de toute évidence, de nombreux développeurs adoptent cette approche. Cet article traite de la différence entre les annonces natives et le Web.
Richesse des caractéristiques
Point: les annonces natives offrent davantage de possibilités
Nous pouvons diviser les fonctionnalités mobiles en deux dimensions: l'expérience de l'application elle-même et la façon dont elle s'intègre à l'écosystème de l'appareil. Par exemple, pour Android, il s'agit de fonctionnalités telles que les widgets et les notifications. Le format natif excelle dans les deux domaines.
En termes d'expérience utilisateur, les applications natives offrent davantage de possibilités. Ils peuvent facilement accéder aux événements de balayage, même tactiles, pour les plates-formes compatibles. Elles peuvent généralement agir sur des touches physiques sur lesquelles l'utilisateur appuie, comme le bouton de recherche et les commandes de volume d'Android. Ils peuvent également accéder au matériel, comme le GPS et l'appareil photo. Et avec l'autorisation de l'utilisateur, certaines plates-formes offrent un accès illimité au système d'exploitation. Essayez simplement de vérifier l'autonomie restante de la batterie avec HTML5.
Mais il ne s'agit pas seulement de l'expérience dans l'application. Un système d'exploitation tel qu'Android offre différentes manières aux applications d'interagir avec les utilisateurs et, de fait, avec d'autres applications. La page d'accueil comporte des widgets actifs. Des notifications s'affichent dans la barre d'état de l'appareil. Vous avez aussi des intents, qui permettent à votre application de se présenter comme étant un service général que d'autres applications peuvent avoir besoin à l'occasion.
À noter: il est possible d'améliorer les fonctionnalités natives, et le Web rattrape son retard.
Il est vrai que de nombreuses fonctionnalités intégrées aux applications HTML5 sont tout simplement inouïes. Peu importe le niveau de connaissances en matière de Web, si votre application est coincée dans un bac à sable sans API d'appareil photo, elle ne sera pas très rapide. Heureusement, vous n'avez pas besoin d'être dans ce bac à sable. Si vous avez vraiment besoin que votre application Web prenne une photo, vous pouvez créer une application native, avec une vue Web intégrée qui fournit la majeure partie de l'interface utilisateur. C'est ainsi que fonctionne le framework Open Source PhoneGap: il comble cette lacune en exposant les fonctionnalités natives en tant que services Web, que la vue Web appelle à l'aide d'une API de mise en réseau standard. Lorsque vous créez une application hybride comme celle-ci, vous pouvez également exploiter ces fonctionnalités de la plate-forme telles que les widgets, les notifications et les intents.
Créer une application hybride native et Web n'est pas une solution idéale. Elle ajoute de la complexité et ne s'applique qu'aux applications Web encapsulées en tant qu'applications natives, plutôt qu'aux sites Web traditionnels accessibles depuis un navigateur mobile. Mais cela ne sera peut-être pas nécessaire pendant longtemps. Les normes Web évoluent rapidement et les navigateurs mobiles modernes suivent le rythme. Par exemple, le stockage hors connexion, la géolocalisation, les images sur toile et la lecture vidéo/audio sont largement compatibles avec les smartphones modernes. L'appareil photo commence à être compatible : à partir d'Android 3.1, il est possible de prendre des photos et des vidéos à l'aide des normes Web. Le dernier navigateur iOS est également compatible avec WebSocket pour le streaming bidirectionnel, ainsi que pour la détection de l'orientation de l'appareil.
Dans l'ensemble, les appareils mobiles évoluent. Mais le Web évolue aussi rapidement. Parmi les navigateurs pour ordinateur, cinq principaux fournisseurs de navigateurs font évoluer leurs normes et ajoutent des fonctionnalités à la vitesse de l'éclair. Bien qu'il ne soit pas facile de transférer ces fonctionnalités sur les mobiles, bon nombre d'entre elles ont déjà intégré les navigateurs mobiles.
Les annonces natives évoluent rapidement, mais le Web comble cette lacune.
Performances
Point: les annonces natives s'exécutent plus rapidement
Les applications natives ne sont pas confrontées à la barrière de l'environnement d'exécution Web. Ils sont très proches et peuvent bénéficier d'outils d'amélioration des performances tels que l'accélération du GPU et le multithreading.
À noter: Les environnements d'exécution Web sont aujourd'hui beaucoup plus rapides, et la plupart des applications n'en ont pas besoin de toute façon.
Dire que le Web est devenu plus rapide ces dernières années, ce serait un euphémisme. V8, le moteur JavaScript intégré à Chrome, constituait un développement majeur en termes de performances Web lors de son lancement. Depuis, il n'a fait que gagner en rapidité:
Les moteurs de rendu graphique ont également accéléré le Web, et l'accélération matérielle commence maintenant à se produire. Examinez l'accélération de la vitesse fournie par le canevas avec accélération matérielle:
De plus, la nouvelle API Web Workers rend le multithreading, et les développeurs Web modernes peuvent également faire appel à toute une gamme de bibliothèques aux performances optimisées et à des techniques d'optimisation des performances bien documentées. Bien que la plupart d'entre eux aient commencé leur vie sur le Web pour ordinateur, ils restent pertinents pour les mobiles, et l'attention est de plus en plus appréciée. Par exemple, Steve Souders, expert en performances, a créé une page dédiée aux outils d'amélioration des performances sur mobile.
Toutes les avancées sur ordinateur ne sont pas encore parvenues à toutes les plates-formes mobiles, mais les tendances indiquent qu'elles sont en passe de devenir disponibles. Il est également important de noter que la plupart des applications mobiles ne sont pas des jeux 3D de pointe, mais essentiellement basés sur des informations: actualités, e-mails, horaires, réseaux sociaux, etc. Accédez à quelques sites depuis votre mobile, tels que Gmail, Amazon, Twitter, et vérifiez que les performances du Web mobile sont plus que adéquates. En ce qui concerne les jeux, les canevas de base sont déjà compatibles avec le canevas 2D, et WebGL commence à apparaître sur les mobiles (voir Firefox 4). Jusqu'à ce qu'il se généralise, il existe une famille croissante de frameworks qui compilent des applications WebGL en applications natives pouvant exploiter OpenGL, par exemple ImpactJS.
Expérience du développeur
Point: les annonces natives sont plus faciles à développer
Les applications natives utilisent des langages de programmation robustes (par exemple, Java, Goal C et C++) qui ont été conçus pour le développement d'applications complexes et qui ont fait leurs preuves. Les API ont été entièrement conçues pour être compatibles avec la plate-forme concernée. Vous pouvez facilement déboguer des applications dans les émulateurs d'ordinateur de bureau qui fournissent une représentation proche de l'appareil cible.
Le développement Web est particulièrement pénible par la grande diversité des navigateurs et des environnements d'exécution. Lorsque votre application s'exécute, rien ne garantit que la fonctionnalité X sera disponible. Et même si c'est le cas, comment le navigateur va-t-il l'implémenter ? Les normes sont ouvertes à l'interprétation.
À l'inverse: le Web est souvent plus facile à développer, en particulier si vous ciblez plusieurs appareils.
Parlons d'abord des technologies de base. Il est vrai que les normes Web ont été conçues à l'origine à une époque où le Web était essentiellement axé sur les documents, et non sur les applications, avec JavaScript créé et déployé en seulement 10 jours. Mais ils se sont avérés bien plus performants que nous ne l'avions imaginé. Les développeurs Web ont appris à exploiter les parties pertinentes et à apprivoiser les mauvaises, et les modèles sont désormais compris pour une conception évolutive. De plus, les normes ne sont pas figées, et des efforts comme HTML5, CSS3 et EcmaScript Harmony améliorent l'expérience des développeurs. Le fait que vous préfériez C++, Java ou JavaScript fait l'objet de débats religieux et dépend également de votre ancien code base. Mais JavaScript est certainement un concurrent de nos jours.
À l'inverse, l'inconvénient de la fragmentation navigateur/environnement d'exécution réside dans le fait que tous ces environnements existent en premier lieu. Si vous développez une application Android en Java, vous devez disposer d'un port complet vers l'Objectif C pour prendre en charge iOS. Développez une application Web une seule fois pour qu'elle s'exécute sur Android et iOS, sans parler de WebOS, BlackBerry, Windows Mobile et... c'est tout de même la théorie. En pratique, vous devrez ajuster des éléments pour chaque plate-forme si vous voulez vraiment une expérience utilisateur de qualité. Mais vous devez aussi le faire en natif. Pour la plupart des systèmes d'exploitation mobiles, il existe différentes versions et différents appareils.
La bonne nouvelle est que la "fragmentation" a toujours été utilisée de cette manière sur le Web, et qu'il existe des techniques bien connues pour gérer cette fragmentation. Plus important encore, le principe d'amélioration progressive oblige les développeurs à cibler d'abord un appareil de base, puis à ajouter des fonctionnalités propres à la plate-forme, le cas échéant. Le mantra de la détection de caractéristiques est également utile. À l'heure actuelle, nous prenons en charge le responsive web design, avec des bibliothèques comme Modernizr. En utilisant judicieusement ces techniques, vous pouvez étendre votre couverture à la grande majorité des appareils, même aux "téléphones multifonctions", même à des facteurs de forme tels que les montres et les téléviseurs, quels que soient leur marque et leur système d'exploitation. Assistez à notre démonstration avec plusieurs interfaces utilisateur lors de la conférence Google IO 2011, au cours de laquelle nous avons ciblé des facteurs de forme distincts (feature phone, smartphone, tablette, ordinateur, téléviseur) avec un code base commun de logique et de balisage.
Aspect général
Point: Le format natif s'adapte à l'aspect de la plate-forme
L'une des caractéristiques clés de toute plate-forme est son apparence. Les utilisateurs s'attendent à ce que les commandes soient présentées de manière cohérente et manipulées de la même manière. Certains idiomes varient d'une plate-forme à l'autre. Par exemple, que se passe-t-il lorsque l'utilisateur effectue une "appui longue" (continuez à appuyer sur un élément pendant plusieurs secondes) ? Les plates-formes comportent des expressions standards pour ces éléments, et vous ne pouvez pas toutes les satisfaire avec une seule application HTML5.
De plus, l'apparence de la plate-forme est orchestrée par la bibliothèque logicielle native de celle-ci, dont les widgets encapsulent l'apparence attendue par les utilisateurs. Rien qu'en utilisant le kit d'outils natif, vous obtenez une grande partie de l'apparence attendue.
À l'inverse, le Web a son propre style, mais vous pouvez aussi personnaliser son interface en fonction des plates-formes qui vous intéressent le plus.
Comme expliqué dans la section précédente, le développement Web consiste à écrire une version de base unique, puis à l'améliorer progressivement. Bien que l'amélioration repose généralement sur des caractéristiques, vous pouvez également la cibler en ciblant les plates-formes qui vous intéressent le plus. Il s'agit d'une sorte de "détection de navigateur", qui est parfois mal perçue par la communauté Web, principalement parce qu'il existe un grand nombre de navigateurs possibles. Toutefois, si vous examinez deux ou trois plates-formes avec une priorité très élevée et que vous êtes prêt à fournir des efforts supplémentaires pour vous empiler par rapport aux alternatives natives, c'est peut-être la solution.
En ce qui concerne la version de référence, le Web a sa propre apparence, et nous pouvons même dire que chaque plate-forme mobile possède sa propre apparence Web définie par le navigateur par défaut et l'environnement d'exécution Web. L'apparence du Web peut convenir à vos utilisateurs. En réalité, elle vous permet d'obtenir une plus grande cohérence avec l'expérience de navigation sur ordinateur et avec celles des autres appareils avec lesquels l'utilisateur travaille. De plus, de nombreuses applications florissantes ne sont pas vraiment compatibles avec l'apparence native. Cela est certainement vrai pour les jeux (votre jeu mobile préféré suit-il l'apparence et la convivialité de votre système d'exploitation mobile ?), et même pour les applications plus conventionnelles, par exemple en examinant les clients Twitter natifs les plus populaires sur la plate-forme de votre choix, et vous verrez un large éventail de mécanismes d'interface utilisateur à l'œuvre.
Visibilité
Important: Les applications natives sont plus faciles à trouver
Les mécanismes de distribution d'applications, tels qu'Android Market et l'App Store d'Apple, ont été extrêmement populaires ces dernières années et jouent un rôle déterminant dans l'ensemble du secteur du mobile. Tout développeur peut soumettre son application native à la place de marché, où les utilisateurs peuvent la découvrir en parcourant, en recherchant et en obtenant des recommandations. De plus, si vous avez bien fait votre travail, les notes et les commentaires élogieux convaincront les utilisateurs de cliquer sur le bouton d'installation très important.
Les applications Web sont en fait plus faciles à trouver.
Le Web est sans doute le support le plus facile à trouver. L'URL simple comporte (en théorie, du moins) un identifiant unique pour tout ce qui est publié sur le Web, y compris les applications publiées sur des sites Web standards. Les moteurs de recherche permettent de découvrir facilement que du contenu et d'autres sites Web peuvent rediriger vers celui-ci, y compris des catalogues d'applications Web semblables aux places de marché mobiles. En effet, n'importe quel utilisateur peut partager des applications Web avec ses amis en ajoutant simplement un lien vers celles-ci dans des e-mails et des messages sur les réseaux sociaux. Les liens peuvent également être envoyés par SMS, où les utilisateurs mobiles peuvent cliquer dessus et lancer l'application dans le navigateur de leur appareil.
Il n'existe pas encore de places de marché où les utilisateurs peuvent évaluer et commenter des applications, mais cela change également. Lisez ce qui suit...
Monétisation
Remarque: Les annonces natives peuvent être monétisées.
"une enfant de 6 ans crée une application à l'heure du déjeuner et vend des millions d'exemplaires à 3 $chacun". Ce titre est souvent visible de nos jours. Il n'est donc pas étonnant que les développeurs, petits ou grands, se tournent vers les places de marché du mobile pour monétiser leurs contenus. Les plates-formes mobiles offrent aux développeurs plusieurs moyens de facturer directement leurs applications. Le plus simple est le paiement unique, pour déverrouiller l'application pour l'éternité. Des mécanismes de paiement et d'abonnement intégrés aux applications sont également disponibles sur certaines plates-formes. Ils sont étroitement intégrés dans un mécanisme cohérent et sécurisé. Ces nouveaux modes de paiement permettent aux développeurs de transformer une application populaire en source de revenus à long terme.
En plus des paiements pour l'application, vous pouvez la monétiser avec des modèles Web traditionnels, tels que la publicité et le sponsoring.
À l'inverse, il a toujours été possible de monétiser le Web, et les opportunités se multiplient
Le Web ne serait pas le moteur de l'industrie moderne s'il n'y avait pas de nombreuses opportunités d'en tirer profit. Bien que les mécanismes directs de "paiement à l'utilisation" n'aient pas encore prospéré, il existe plusieurs niveaux où les solutions de logiciel en tant que service basées sur abonnement sont effectivement devenues viables. Exemples : Google Apps, la gamme de produits 37Signals et les versions premium de divers services de messagerie. De plus, les paiements directs ne sont pas le seul moyen de profiter des applications Web. La publicité en ligne, les liens d'affiliation, le sponsoring, la promotion croisée vers d'autres produits et services.
Cela étant dit, il est tout à fait raisonnable pour un développeur Web de lire les titres et de ressentir une vague d'envie de paiement. Vous ne pouvez pas envoyer d'URL Web aux places de marché natives. Que doit faire un développeur Web ? Vous devez créer une "application de wrapper" native. Pour chaque plate-forme que vous souhaitez cibler, créez une application native vide qui contient simplement une vue Web. La vue Web est l'endroit où vous intégrez la véritable application. Il vous suffit ensuite de les envoyer aux différentes places de marché (et, avec un peu de chance, de voir le résultat de l'argent !). Il existe probablement des centaines, voire des milliers, d'applications Web sur les principaux marchés aujourd'hui. Certaines d'entre elles ont été assimilées de manière si astucieuse que nous ne connaissons même pas du tout leurs applications Web.
L'inconvénient est de procéder à une compilation croisée entre chaque plate-forme. C'est là qu'un framework existant comme PhoneGap peut vous aider. Mieux encore, des services Web tels que PhoneGap Build et Apparatio sont en cours de développement. Faites pointer ces sites Web vers votre dépôt de code, puis affichez une application Android, une application iOS, etc., prête à être envoyée aux magasins concernés. Vous n'avez pas besoin d'installer de SDK natifs sur votre ordinateur. Pour créer toutes ces applications natives, il vous suffisait d'un éditeur de code et d'un navigateur Web.
Les places de marché prennent-elles directement en charge les applications Web, sans avoir à les encapsuler de manière native ? Ce n'est pas encore clair. Nous savons que Google a lancé le Chrome Web Store l'année dernière. Bien qu'il ne s'applique qu'aux ordinateurs de bureau, la boutique a suscité l'intérêt d'autres fournisseurs de navigateurs et fait partie intégrante d'une tendance en matière de catalogues d'applications Web, y compris certaines tentatives spécifiques aux mobiles. Le concept de boutique en ligne n'en est qu'à ses débuts, mais les enseignes sont prometteuses.
Conclusions
Il serait intéressant de déclarer un gagnant ici, mais pour l'instant, il n'y a pas de gagnant précis. Certaines applications conviennent particulièrement au format natif, tandis que d'autres sont plus adaptées au Web. La pile Web est sans doute plus dynamique, mais en termes de capacités et de qualités d'exécution, les applications natives évoluent également rapidement. À moins que les technologies Web ne soient utilisées par la majorité des systèmes d'exploitation mobiles, les annonces natives seront toujours un critère important.
L'une des techniques mentionnées dans cet article concerne les applications hybrides. Il peut s'agir du meilleur compromis pour certains développeurs: la vue Web lorsque cela est possible et les composants natifs spécifiques à la plate-forme dans le cas contraire.
Si vous choisissez le chemin Web, tenez compte des normes du Web et du principe de l'amélioration progressive. Le Web est une technologie qui sait comment cibler la multitude d'appareils et de systèmes d'exploitation qui l'entourent. Que vous choisissiez de l'appeler "fragmentation" ou "diversité", le Web l'accepte, et vos développeurs peuvent bénéficier de tout l'art antérieur.