Le débat sur l'application mobile
Introduction
Les applications mobiles et HTML5 sont deux des technologies les plus populaires du moment, et elles se chevauchent souvent. Les applications Web s'exécutent dans les navigateurs mobiles et peuvent également être reconditionnées en tant qu'applications natives sur les différentes plates-formes mobiles. Compte tenu du large éventail de plates-formes à prendre en charge, combiné à la puissance des navigateurs mobiles, les développeurs se tournent vers HTML5 comme solution "écrire une fois, exécuter partout". Mais est-ce vraiment viable ? Il existe encore de bonnes raisons de passer au natif, et de nombreux développeurs le font. Cet article est un débat sur le natif par rapport au Web.
Richesse des fonctionnalités
Point : les applications natives peuvent faire plus
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. Native excelle dans les deux dimensions.
En termes d'expérience utilisateur, les applications natives sont plus performantes. Ils peuvent facilement obtenir des événements de balayage, même multitouch, pour les plates-formes qui le prennent en charge. Ils peuvent généralement réagir à l'appui sur des touches physiques, comme le bouton de recherche et les commandes de volume d'Android. Elles peuvent également accéder au matériel, comme le GPS et l'appareil photo. Avec l'autorisation de l'utilisateur, certaines plates-formes offrent un accès illimité au système d'exploitation. Essayez simplement de détecter 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 comme Android offre différentes façons aux applications d'interagir avec les utilisateurs, et même avec d'autres applications. Vous avez des widgets actifs sur la page d'accueil. Vous avez des notifications qui s'affichent dans la barre d'état de l'appareil. Vous disposez également d'intentions, qui permettent à votre application de se présenter comme fournissant un service général dont d'autres applications peuvent avoir besoin à l'occasion.
Contre-argument : les fonctionnalités natives peuvent être augmentées, et le Web est de toute façon en train de rattraper son retard
Il est vrai que de nombreuses fonctionnalités intégrées aux applications sont tout simplement hors de portée pour une application HTML5. Peu importe votre niveau de maîtrise du Web, si votre application est bloquée dans un bac à sable sans API d'appareil photo, elle ne prendra pas de photos de sitôt ! 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 le fossé en exposant les fonctionnalités natives en tant que services Web, que la vue Web appelle à l'aide d'une API réseau standard. Lorsque vous créez une application hybride comme celle-ci, vous pouvez également vous connecter à ces fonctionnalités de plate-forme, comme les widgets, les notifications et les intents.
La création d'une application hybride (native et Web) n'est pas une solution idéale. Il 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 graphiques Canvas et la lecture vidéo/audio sont largement pris en charge par les smartphones modernes. L'appareil photo est également pris en charge : depuis Android 3.1, il est possible de prendre des photos et des vidéos à l'aide des normes Web. Le dernier navigateur iOS est compatible avec WebSocket pour le streaming bidirectionnel, ainsi qu'avec la détection de l'orientation de l'appareil.
Le mobile évolue. Mais le Web évolue aussi, et rapidement. Rien que pour les navigateurs pour ordinateur, cinq grands fournisseurs de navigateurs font évoluer les normes et ajoutent des fonctionnalités à une vitesse fulgurante. Bien que le portage de ces fonctionnalités sur mobile ne soit pas un processus trivial, beaucoup d'entre elles ont déjà été intégrées aux navigateurs mobiles.
Le natif est une cible mouvante, mais le Web réduit l'écart.
Performances
Point : le format natif est plus rapide
Les applications natives n'ont pas à gérer la barrière d'exécution Web. Elles s'exécutent près du matériel et peuvent tirer parti des boosters de performances tels que l'accélération GPU et le multithreading.
Contre-argument : les runtimes Web sont beaucoup plus rapides aujourd'hui, et la plupart des applications n'ont pas besoin de cette vitesse.
Dire que le Web est devenu plus rapide ces dernières années serait un euphémisme. V8, le moteur JavaScript fourni avec Chrome, a représenté une avancée majeure en termes de performances Web lors de son lancement. Depuis, il n'a fait que s'améliorer :
Les moteurs de rendu graphique ont également accéléré le Web, et l'accélération matérielle commence à se produire. Voici un exemple de ralentissement fourni par le canevas à accélération matérielle :
De plus, la nouvelle API Web Workers permet le multithreading. Les développeurs Web modernes peuvent également faire appel à une gamme de bibliothèques optimisées pour les performances et à des techniques d'optimisation des performances bien étudiées. Bien que la plupart d'entre eux aient été conçus pour le Web sur ordinateur, ils restent pertinents pour le mobile.De plus, l'attention portée au mobile est de plus en plus importante. Par exemple, Steve Souders, gourou des performances, a une page dédiée aux outils de performances mobiles.
Toutes les avancées sur ordinateur ne sont pas encore disponibles sur toutes les plates-formes mobiles, mais les tendances indiquent qu'elles le seront bientôt. Il est également important de noter que la majorité des applications mobiles ne sont pas des jeux 3D de pointe, mais sont fondamentalement basées sur l'information : actualités, e-mails, emplois du temps, réseaux sociaux, etc. Consultez quelques sites depuis votre mobile, par exemple Gmail, Amazon ou Twitter, et vous pourrez constater que les performances Web sur mobile sont plus que suffisantes. Quant aux jeux, les jeux de base sont déjà réalisables avec le canevas 2D, et WebGL commence à apparaître sur les mobiles (voir Firefox 4). En attendant que WebGL se généralise, une famille de frameworks de plus en plus importante compile les applications WebGL en applications natives pouvant tirer parti d'OpenGL, par exemple ImpactJS.
Expérience développeur
Argument : le développement natif est plus facile
Les applications natives utilisent des langages de programmation robustes (Java, Objective C, C++, etc.) conçus pour le développement d'applications complexes et qui ont fait leurs preuves. Les API ont été conçues dès le départ pour prendre en charge la plate-forme en question. Vous pouvez facilement déboguer des applications dans des émulateurs de bureau qui représentent fidèlement l'appareil cible.
Le développement Web est particulièrement problématique en raison de la grande diversité des navigateurs et des environnements d'exécution. Lorsque votre application s'exécute, la disponibilité de la fonctionnalité X n'est pas garantie. Et même si c'est le cas, comment le navigateur va-t-il l'implémenter ? Les normes peuvent être interprétées de différentes manières.
Contre-argument : le Web est souvent plus facile à développer, en particulier si vous ciblez plusieurs appareils
Commençons par la technologie de base. Il est vrai que les normes Web ont été initialement conçues à une époque où le Web était fondamentalement axé sur les documents, et non sur les applications, avec JavaScript conçu et déployé en seulement 10 jours. Mais ils se sont avérés beaucoup plus performants que prévu : les développeurs Web ont appris à exploiter les bons aspects et à maîtriser les mauvais, avec des modèles désormais compris pour une conception évolutive. De plus, les normes ne sont pas figées et des efforts tels que HTML5, CSS3 et EcmaScript Harmony améliorent tous l'expérience des développeurs. Que vous préfériez C++, Java ou JavaScript est une question de débat religieux, et dépend également de votre ancienne base de code. Mais nous pouvons certainement inclure JavaScript comme un concurrent sérieux de nos jours.
L'autre côté de la fragmentation des navigateurs/environnements d'exécution est le fait que tous ces environnements existent en premier lieu. Vous développez une application Android en Java et vous devez la porter entièrement en Objective C pour qu'elle soit compatible avec iOS. Développez une application Web une seule fois, et elle s'exécutera sur Android et iOS, sans oublier WebOS, BlackBerry, Windows Mobile et… enfin, c'est la théorie. En pratique, vous devrez ajuster les paramètres pour chaque plate-forme si vous voulez vraiment offrir une expérience optimale. Mais vous devriez également le faire en natif pour la plupart des systèmes d'exploitation mobiles, car il existe différentes versions et différents appareils.
La bonne nouvelle, c'est que la "fragmentation" a toujours existé sur le Web, et qu'il existe des techniques bien connues pour y faire face. Plus important encore, le principe de l'amélioration progressive incite les développeurs à cibler d'abord un appareil de base, puis à ajouter des couches de fonctionnalités spécifiques à la plate-forme lorsqu'elles sont disponibles. Le mantra de la détection de fonctionnalités est également utile. De nos jours, nous disposons d'une bibliothèque d'assistance, comme Modernizr, pour prendre en charge le Responsive Web Design. En utilisant judicieusement ces techniques, vous pouvez étendre votre couverture à la grande majorité des appareils, y compris les "feature phones" à l'ancienne, et même les facteurs de forme tels que les montres et les téléviseurs, quelle que soit la marque et l'OS. Découvrez notre démonstration multi-UI lors de la Google IO 2011, où nous avons ciblé différents facteurs de forme (téléphone mobile, smartphone, tablette, ordinateur, téléviseur) avec une base de code commune de logique et de balisage.
Look-And-Feel
Point : l'apparence et l'ergonomie de la plate-forme Native sont respectées
L'une des caractéristiques déterminantes 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 un appui prolongé (en gardant le doigt sur un élément pendant plusieurs secondes) ? Les plates-formes ont des idiomes standards pour ce genre de choses, et vous ne pouvez pas tous 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 la plate-forme, dont les widgets encapsulent le type d'apparence attendu par les utilisateurs. Vous obtenez une grande partie de l'apparence attendue "sans frais" en utilisant simplement la boîte à outils native.
Contre-argument : le Web a sa propre apparence. Vous pouvez également personnaliser l'interface Web pour les 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 "universelle", puis à l'améliorer progressivement. Bien que l'amélioration soit généralement basée sur des fonctionnalités, vous pouvez également l'améliorer en ciblant les plates-formes qui vous intéressent le plus. Il s'agit d'une sorte de "détection du navigateur", qui est parfois mal vue par la communauté Web, principalement parce qu'il existe de nombreux navigateurs possibles. Toutefois, si vous considérez deux ou trois plates-formes comme très prioritaires et que vous êtes prêt à faire un effort supplémentaire pour rivaliser avec les alternatives natives, cette option peut être intéressante.
En ce qui concerne la version de base, le Web a sa propre apparence. On peut même dire que chaque plate-forme mobile a sa propre "apparence Web" établie par le navigateur et le moteur d'exécution Web par défaut. L'apparence Web peut convenir à vos utilisateurs et vous permettre d'obtenir une plus grande cohérence avec l'expérience de navigation sur ordinateur, ainsi que sur les autres appareils que l'utilisateur peut utiliser. De plus, de nombreuses applications à succès ne prennent pas en charge l'apparence et l'expérience natives. C'est certainement le cas des jeux (votre jeu mobile préféré suit-il l'apparence de votre OS mobile ?), et même des applications plus conventionnelles. Par exemple, consultez les clients Twitter natifs les plus populaires sur la plate-forme de votre choix, et vous verrez une large gamme de mécanismes d'interface utilisateur à l'œuvre.
Visibilité
Argument : les applications natives sont plus faciles à découvrir
Les mécanismes de distribution d'applications, comme l'Android Market et l'App Store d'Apple, ont connu un succès retentissant ces dernières années et sont une force motrice majeure pour l'ensemble du secteur mobile. Tout développeur peut envoyer son application native sur la marketplace, où les utilisateurs peuvent la découvrir en parcourant, en recherchant et en recevant des recommandations. De plus, si vous avez fait votre travail correctement, les notes et les commentaires élogieux convaincront les utilisateurs d'appuyer sur le bouton d'installation, qui est essentiel.
Contre-argument : en fait, les applications Web sont plus faciles à découvrir
Le Web est sans doute le support le plus propice à la découverte jamais créé. En théorie, l'humble URL est un identifiant unique pour tout ce qui a été publié sur le Web, y compris les applications publiées sur des sites Web standards. Les moteurs de recherche permettent de découvrir facilement ce contenu, et d'autres sites Web peuvent y créer des liens, y compris des catalogues d'applications Web semblables aux plates-formes de téléchargement d'applications mobiles. En effet, n'importe quel utilisateur peut partager des applications Web avec ses amis en leur envoyant simplement un lien par e-mail ou sur les réseaux sociaux. Les liens peuvent également être envoyés par SMS. Les utilisateurs mobiles pourront alors cliquer dessus et lancer l'application dans le navigateur de leur appareil.
Nous ne disposons pas encore des mêmes plates-formes sur lesquelles les utilisateurs peuvent évaluer et commenter les applications, mais cela va changer. Lire la suite…
Monétisation
Point : les contenus natifs peuvent être monétisés
"Un enfant de six ans crée une application pendant sa pause déjeuner et en vend un milliard d'exemplaires à 3 $ chacun". Vous voyez souvent ce titre de nos jours. Il n'est donc pas étonnant que les développeurs, petits et grands, se tournent vers les places de marché mobiles pour la monétisation. Les plates-formes mobiles offrent aux développeurs plusieurs moyens de facturer directement leurs applications. Le plus simple est le paiement unique, qui permet de déverrouiller l'application pour toujours. Certaines plates-formes proposent également des mécanismes de paiement et d'abonnement intégrés aux applications, qui 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 à succès en source de revenus à long terme.
En plus des paiements via l'application, vous pouvez monétiser vos contenus avec des modèles Web traditionnels, tels que la publicité et le sponsoring.
Contre-argument : il a toujours été possible de monétiser du contenu sur le Web, et les opportunités se multiplient
Le Web ne serait pas le moteur de l'industrie moderne s'il n'offrait pas de nombreuses opportunités de gagner de l'argent. Bien que les mécanismes de paiement à l'utilisation directe n'aient pas encore prospéré, il existe diverses niches où les solutions de logiciel en tant que service par abonnement sont devenues viables. Par exemple, les applications Google, 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 générer des revenus avec les applications Web. Il existe de nombreuses façons de promouvoir votre chaîne : publicité en ligne, liens affiliés, sponsoring, promotion croisée vers d'autres produits et services, etc.
Cela dit, il est tout à fait normal qu'un développeur Web lise les gros titres et ressente une pointe d'envie vis-à-vis des paiements. Vous ne pouvez pas envoyer d'URL Web aux plates-formes de téléchargement natives. Que doit faire un développeur Web ? Pour ce faire, vous devez créer une "application wrapper" native. Pour chaque plate-forme cible, 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 d'envoyer ces applications aux différentes places de marché (et, espérons-le, de voir l'argent affluer !). Il existe probablement des centaines, voire des milliers, d'applications Web sur les principales plates-formes de téléchargement aujourd'hui. Certaines d'entre elles sont si astucieusement assimilées que nous ne connaissons même pas leurs applications Web.
L'inconvénient est que la compilation croisée incombe à chaque plate-forme. C'est là qu'un framework existant comme PhoneGap peut vous aider. Mieux encore, des services Web comme PhoneGap Build et Apparatio sont en cours de développement. Indiquez ces sites Web à votre dépôt de code, et une application Android, une application iOS, etc. apparaîtront, prêtes à être envoyées aux magasins respectifs. Vous n'avez pas besoin d'installer de SDK natifs sur votre machine. Tout ce dont vous avez besoin pour créer toutes ces applications natives, c'est d'un éditeur de code et d'un navigateur Web.
Les plates-formes prendront-elles un jour en charge les applications Web directement, sans la surcharge liée à leur encapsulation native ? Nous ne le savons pas encore. Nous savons que Google a lancé le Chrome Web Store l'année dernière. Bien qu'il ne s'applique qu'au bureau, le store a suscité l'intérêt d'autres fournisseurs de navigateurs et s'inscrit dans une tendance générale aux catalogues d'applications Web, y compris certaines tentatives spécifiques aux mobiles. Le concept de boutique en ligne en est encore à ses débuts, mais les signes sont prometteurs.
Conclusions
Il serait agréable de déclarer un vainqueur ici, mais pour le moment, il n'y en a pas de clair. Certaines applications sont mieux adaptées au natif et d'autres au Web. La pile Web a sans doute plus d'élan, mais en termes de capacités et de qualités d'exécution, les applications natives progressent également rapidement. Et tant que les technologies Web ne seront pas considérées comme des éléments à part entière sur la majorité des OS mobiles, le natif restera une option importante.
Cet article mentionne les applications hybrides, qui peuvent être le meilleur compromis pour certains développeurs : vue Web lorsque c'est possible et composants natifs spécifiques à la plate-forme lorsque ce n'est pas le cas.
Si vous choisissez le chemin Web, tenez compte des normes Web et du principe d'amélioration progressive. Le Web est une technologie qui sait comment cibler la multitude d'appareils et de systèmes d'exploitation existants. Que vous choisissiez de l'appeler "fragmentation" ou "diversité", le Web l'adopte et vous, les développeurs, pouvez bénéficier de tout l'art antérieur disponible.