Extrait de l'émission CPU release Ex0250 : Et l'URL disparu.
J'ai donc évoqué l'origine des WebApps, et qu'une de leurs propriétés fait que n'importe quelle vue est une URL. Et vous vous demandez sûrement pourquoi Google a développé en parallèle Chrome OS et son OS natif Android ? Cette diversification est aussi une question de culture : résoudre des problèmes que d'autres équipes verront ou intégrer des fonctionnalités top moumoutes qui séduisent le public.
Revenons au contexte : celui des glorieuses premières versions d'Android en 2009, où les développeurs voyaient d'un coup apparaître de nouveaux smartphones avec de nouvelles tailles d'écran.
Or, dans les premières API d'Android et d'iPhone, il fallait placer au pixel chaque élément de l'interface. Ce qui n'était pas déconnant aux débuts d'un écosystème quand il n'avait qu'une ou deux tailles d'écrans. Donc, il n'était pas rare de voir des applications qui soit n'entraient pas complètement dans l'écran d'un petit smartphone, soit affichaient de grandes bandes noires sur le côté, faute de remplir complètement la place. Ça arrivait même aux éditeurs de grosses applications, comme celle de Radio France. Et pour être honnête, on l'a vu aussi dans des applications pour iOS, quand l'iPhone 5 est passé de 320×480 pixels à 640×1136.
Sauf que construire une interface Android native à l'époque, c'est du code Java et un document XML par vue, par orientation et par résolution à exprimer en pixels. Un enfer à maintenir, il faut démultiplier les fichiers définitions par taille d'écran.
Autre problème : bien souvent, les applications mobiles avaient aussi une version web, ce qui veut dire que les développeurs doivent développer à la fois l'interface web pour ordinateurs de bureau, celle pour téléphones mobiles, l'application Android et l'application iOS.
Pour y pallier, les développeurs d'applications natives ont utilisé un élément d'interface : la WebView. Une instance d'un navigateur web, dans le cas d'Android, Chrome, et chez Apple, Webkit, avec strictement aucun élément d'interface de ce navigateur : ni menu, ni bouton de navigation, ni barre d'URL.
Cette WebView peut s'insérer dans une application, vue qui peut se modifier dynamiquement directement depuis votre code, qu'il peut être écrite en Java, en Kotlin dans Android ou pour iOS en Objective-C ou en Swift. D'ailleurs, une WebView a accès à bien plus d'outils systèmes et de permissions qu'une page web affichée dans le navigateur web habituel ; alors que paradoxalement, le moteur de rendu du mode WebView accusait souvent quelques versions de retard par rapport au navigateur web complet.
Quelle est la différence intrinsèque entre une interface construite nativement et une page web dans une WebView ? Le fait que les nouvelles propriétés CSS permettaient de construire en Responsive Web Design. Qu'on pense en mise en page élastique ou liquide, le design d'un site web peut désormais, en partant d'un même fichier HTML quel que soit l'écran qui l'affichera, positionner chaque élément en le coulant dans la forme de l'écran.
Une WebView simplifie la construction d'une interface, d'avoir un aspect uniforme entre le site web et l'application, et permet d'évoluer l'application sans devoir passer par la publication d'une mise à jour sur Google Play ou Apple App Store.
D'un coup, la mise en forme d'une application native mobile n'est plus du ressort des développeurs mais des mêmes intégrateurs qui construisent le HTML et la CSS que le site web. Et si de nouvelles dimensions ou formes d'écran arrivent, et que les intégrateurs ont parfaitement appliqué l'état de l'art en Responsive Web Design, alors l'application est déjà prête.
Les SDK d'applications natives intégrèrent rapidement l'idée d'une d'interface plus plastique, plus élastique, plus liquide, plutôt qu'un canevas fixé en pixels absolus.
Autre évolution pour les développeurs ; on pouvait penser une vue comme une URL. Donc partager la vue d'une application avec d'autres, et un fallback vers la page web si l'application partagée n'est pas installée ; ou encore faire un lien d'une application vers une vue d'une autre application. L'idée des OS en HTML5 que l'URL puisse se retrouver n'importe où dans un OS fait du chemin et s'intègre au fur et à mesure dans les SDK d'Android et iOS. Et, à la différence de ce que faisait Apple pour son iTunes Music Store ou Microsoft en général, plutôt que de créer des protocoles au taquet, l'OS ou le navigateur pouvaient réagir en fonction du nom de domaine d'un site web et donc lancer l'appli idoine.
Et en 2015 arrive React Native, qui permet en un seul code javascript ou typescript, de produire à la fois le site web et les appli natives avec des comportements cohérents. On n'est plus dans une WebView, l'appli native est plus véloce et les développeurs profitent des frameworks, des outils de mise en forme et de débuggage venus du web.
Une excellente réponse au fait qu'Apple refusait obstinément les WebApp sur iOS.
Texte : Da Scritch,
Illustration : cc-0 MaxPixel