Au beau milieu de la bataille judiciaire qui oppose Epic à Apple, et avec un sens du timing presque trop parfait, une voix vient de se faire entendre, qui pourrait aller à l’encontre du discours rodé du géant californien, selon lequel son écosystème est contrôlé, mais ouvert.
Cette voix, c’est celle d’Alex Russell, développeur de Chrome pendant 12 ans et désormais en charge du projet Fugu, de Google. Son équipe et lui cherchent à réduire l’écart fonctionnel entre le Web et ce que peuvent offrir les applications natives sur un smartphone, par exemple.
Dans une longue note de blog, titrée Un progrès retardé est un progrès perdu, il aborde de manière méthodique la position d’Apple vis-à-vis de son App Store, du Web en tant qu’alternative aux applications natives, et de sa politique concernant les navigateurs sur iOS.
Sans compétition et à la traîne
Tout en prenant des précautions, en mettant en avant la diversité nécessaire d’approche dans la conception d’un navigateur et des choix techniques, tout en rappelant l’excellence des équipes qui travaillent sur WebKit, le moteur au cœur de Safari, Alex Russell pointe du doigt le problème qu’est devenu WebKit, en tant que seule base de navigateur sur iOS. Le cœur se trouve du côté « des règles de l’App Store d’iOS qui empêchent une réelle compétition entre navigateurs », écrit-il.
D’autant que, selon lui, WebKit est à la traîne à cause de choix faits par Apple.
« Le navigateur d’iOS (Safari) et son moteur (WebKit) manquent de puissance. Des retards récurrents dans la livraison de fonctions importantes font en sorte que le Web ne puisse jamais être une alternative crédible aux outils propriétaires d’Apple et à son App Store. », assène-t-il.
Alex Russell s’attelle ensuite à confronter des arguments mis en avant par Apple à la réalité du marché, ou en tout cas à sa propre vision. À chaque grosse mise à jour de Safari, les équipes de Tim Cook mettent en avant les gains de performances de leur navigateur. Des gains réels, vérifiables avec des outils de bench, mais qui n’ont pas une grande valeur, oppose le développeur de Chrome.
« Après vingt ans d’une compétition au coude à coude, souvent en partant d’un héritage de code commun, il n’y a pas grand-chose de plus à pressurer hors du système. »
Et de mettre en avant la nouvelle approche de gestion de la mémoire de Chrome, par exemple, réputé pour être un ogre en la matière, tout en reconnaissant que « tous les navigateurs se livrent à un long voyage d’optimisation, qui impose de complexes compromis. Améliorer les choses pour un type d’appareil ou d’application peut nuire aux autres ».
Puis, Alex Russell de conclure, sur ce point, que la recherche de meilleures performances ne doit surtout pas empêcher l’ajout de fonctions nouvelles, qui améliorent l’expérience utilisateur. Sur ce point, il ne cherche pas un exemple parmi ses faits d’armes, mais il se tourne vers Firefox et l’introduction de Quantum, son nouveau moteur, fin 2017.
Le problème de la compatibilité et de l’ajout de nouvelles fonctions
Pour continuer sa démonstration, le développeur de Google s’attaque ensuite à un autre point essentiel, celui de la compatibilité. Il recourt à différents résultats de tests reconnus (issus des projets comme Web-platform-tests ou Web Confluence Metrics) pour démontrer que Safari est en retard par rapport à ses concurrents, qu’il s’agisse des navigateurs sous Chromium ou de Firefox.
Il montre aussi et surtout que Safari ne progresse pas de manière régulière, mais par à-coups. L’introduction de nouvelles fonctionnalités développées pour le Web arrivent tardivement, lentement. Il prend ainsi le cas de l’intégration du protocole de visioconférence WebRTC, qui aurait été retardé pendant cinq ans avant d’intégrer Safari.
Autre exemple, le support de technologies comme WebM et VP8/VP9 (des codecs sans royalties poussés par Google), limitées à certains usages, en l’occurrence le fonctionnement de WebRTC.
Des introductions parcellaires et tardives, donc… Le navigateur d’iOS (sur macOS, Apple procède à des mises à jour indépendantes) est en effet inféodé aux grosses updates du système d’exploitation mobile. Dès lors, il est évident qu’il lui est difficile de lutter contre le rythme de mise à jour de Chrome.
Cette lenteur est d’autant plus regrettable qu’elle ralentit la montée en puissance technique de tous les autres navigateurs sur iOS, qui sont contraints de fonctionner avec WebKit. Dans le meilleur des cas, les développeurs des browsers alternatifs sont obligés de recourir à des astuces pour contourner ces limitations, ces lenteurs.
Alex Russell indique clairement que cette lenteur d’Apple a un impact certain sur ce qu’il est possible de faire sur un iPhone, or le smartphone d’Apple (et les iPad également) pèse lourd sur le marché mondial du Web mobile.
« Supposons qu’Apple ait implémenté WebRTC et l’API Gamepad en temps et en heure. Peut-on envisager que la révolution du streaming de jeux vidéo ait pu avoir lieu plus tôt ? Il est possible qu’Amazon Luna, Nvidia GeForce Now, Google Stadia ou Microsoft xCloud aient pu être construits des années plus tôt. »
Si on comprend le sens de la démonstration, en l’occurrence, il faut garder en tête que ces plates-formes ont rencontré bien d’autres défis avant de pouvoir voir le jour à grande échelle. Néanmoins, ajouter un grain de sable dans l’engrenage n’est évidemment pas sans effet.
A consequence of forced-WebKit-use for all browsers on iOS is that *you don't get safer by switching browsers*, and we can't bring Chrome's aggressive sandboxing to bear on the problem (as we have on every other OS).
Also:https://t.co/ogejUaLor5 https://t.co/WS4k8Yzupm
— Alex Russell (@slightlylate) May 5, 2021
Des fonctions retardées, des questions de sécurité, des progrès mis en pause – comme l’intégration de WebGPU, le successeur de WebGL, qui promet des performances graphiques proches de celles d’API comme Vulkan, Direct3D 12 ou Metal, et des « oublis » gênants.
Ainsi, alors qu’Apple a été un des premiers zélateurs des Progressive Web App, en 2007, ce pan technique important, qui sous-tend les alternatives aux applications natives, semble être resté en jachère depuis.
C’est l’ultime argument d’Alex Russell qui conclut son poste en mettant en opposition ces deux réalités qui semblent difficilement conciliables et qui cohabitent pourtant dans le monde iOS :
« Apple veut que nous acceptions qu’il est raisonnable, d’une part, de forcer les navigateurs iOS à utiliser son moteur Web, laissant iOS être à la traîne, et, d’autre part, que le Web est une alternative viable sur iOS pour les développeurs mécontents des règles régissant son App Store. L’une ou l’autre pourrait être raisonnable. Mais les deux ? »
Un sérieux coup porté à un argumentaire rodé
L’attaque pourrait être bénigne, et se limiter à un reproche technico-technique. Mais sa portée est bien plus importante. Elle met à mal un pan entier de la stratégie de défense d’Apple contre les reproches qui lui sont faits par certains développeurs ou par certaines enquêtes pour abus de position dominante.
En effet, depuis les origines de l’iPhone, pour différentes raisons et avec des objectifs parfois antinomiques, Apple a toujours dit que son système d’exploitation mobile, malgré un kiosque de téléchargements verrouillé, était une plate-forme ouverte puisque les développeurs pouvaient créer des applications Web s’ils ne souhaitaient pas passer par l’App Store.
En 2017, Mark Mayo, alors senior vice-président de Firefox, nous expliquait que les équipes de Firefox, et le monde des développeurs de navigateurs en général n’avaient pas pris la mesure de la révolution applicative, de ce monde séduisant, performant, mais fermé. Il en concevait un regret, déclarant que Firefox avait trahi le Web.
Quelques années plus tard, par un autre chemin et en atteignant un autre but, Alex Russell met en exergue une même réalité. L’opposition entre le monde riche, optimisé, mais fermé et contrôlé des applications et celui plus divers et libre du Web, qu’un navigateur « bridé » rend évidemment moins attractif.
Alors que le procès contre Epic fait rage donc, que les autorités de la concurrence s’intéressent aux géants de la tech, Apple va peut-être devoir expliquer pourquoi iOS et le Web semblent entretenir une relation si ambivalente, si paradoxale, si… déséquilibrée.
Source : Blog d’Alex Russell
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
