Tim Sweeney : Apple aurait délibérément bridé les web apps sur iPhone dans l’UE pour limiter la concurrence
(techcrunch.com)- En réponse au Digital Markets Act (DMA) de l’UE, les fonctionnalités des web apps sur l’écran d’accueil de l’iPhone ont été réduites, et le CEO d’Epic Games, Tim Sweeney, a soulevé la question de savoir si Apple ne cherchait pas à freiner les PWA susceptibles de menacer les revenus de l’App Store
- Apple explique que le DMA l’oblige à autoriser des moteurs de navigateur alternatifs en plus de WebKit, alors que le modèle de sécurité des web apps sur l’écran d’accueil reposait jusqu’ici sur WebKit
- Le fait que les PWA ne fonctionnent plus normalement dans la bêta iOS destinée à l’UE s’est révélé être non pas un simple bug, mais un changement volontaire d’Apple, rapprochant les web apps de simples favoris de sites web privés de stockage local, badges, notifications et fenêtre dédiée
- Apple indique que pour prendre en charge de manière sûre des web apps basées sur des moteurs alternatifs, il faudrait une nouvelle architecture d’intégration absente d’iOS, mais qu’elle ne l’a pas implémentée en raison de la charge liée au DMA et d’un faible taux d’utilisation
- Si des navigateurs concurrents prennent mieux en charge les PWA que Safari, les web apps pourraient devenir un concurrent natif “non taxé”, ce qui met en tension l’argumentaire sécuritaire d’Apple et les perspectives de croissance du marché des PWA
Les web apps sur l’écran d’accueil de l’iPhone réduites dans l’UE
- Apple a confirmé avoir volontairement abaissé les capacités des web apps sur iPhone dans l’UE au nom de la conformité au DMA
- Le problème est apparu récemment lorsque les Progressive Web Apps (PWA) ne se sont plus mises à fonctionner normalement dans la bêta iOS pour l’UE
- Au départ, l’hypothèse d’un bug de bêta avait été avancée, mais Apple a précisé qu’il ne s’agissait pas d’une simple erreur, mais d’un changement de politique
- L’explication correspondante a été ajoutée à la page d’assistance développeurs d’Apple sur le DMA
La logique d’Apple : un modèle de sécurité fondé sur WebKit
- Le DMA impose à Apple de prendre en charge d’autres moteurs de navigateur web que WebKit de Safari
- Les web apps iOS sur l’écran d’accueil ont jusqu’à présent fonctionné sur la base de WebKit et de son architecture de sécurité
- isolation du stockage
- affichage obligatoire de prompts système lors de l’accès à des fonctionnalités ayant un impact sur la vie privée
- Apple explique que sans cette isolation et ces mécanismes obligatoires, des web apps malveillantes pourraient lire les données d’autres apps ou accéder à la caméra, au micro et à la localisation sous couvert du consentement de l’utilisateur
- Résultat, l’expérience des web apps iOS pour les utilisateurs européens a été fortement réduite, et les web apps se comportent en pratique comme de simples favoris de sites web
- pas de prise en charge du stockage local
- pas de prise en charge des badges
- pas de prise en charge des notifications
- pas de prise en charge d’une fenêtre dédiée
La réponse de Tim Sweeney : les PWA sont un concurrent potentiel de l’App Store
- Le CEO d’Epic Games, Tim Sweeney, a publié sur X que la véritable raison pourrait être que les web apps sur iPhone ne rapportent rien à Apple
- Sweeney est le CEO d’Epic Games, qui a poursuivi Apple en justice sur des questions antitrust liées aux commissions de l’App Store, et il a donc un intérêt évident dans ce dossier
- La question est de savoir si la décision d’Apple vise réellement à protéger la sécurité des utilisateurs, ou à réduire une menace potentielle pour son activité
- Sweeney estime que des navigateurs concurrents pourraient prendre en charge les PWA bien mieux que les fonctionnalités web limitées de Safari, auquel cas les PWA deviendraient des “concurrents légitimes et non taxés” des apps natives
Une solution technique existe, mais sa mise en œuvre est suspendue
- Apple reconnaît qu’il existe un moyen technique de résoudre les problèmes de sécurité et de vie privée des web apps utilisant des moteurs alternatifs
- Mais cela nécessiterait de construire une architecture d’intégration entièrement nouvelle qui n’existe pas aujourd’hui dans iOS
- Apple indique que sa réponse au DMA a déjà nécessité “plus de 600 nouvelles API et divers outils pour développeurs”, et juge la création de cette architecture peu pratique en raison du très faible usage des web apps sur l’écran d’accueil
- Le DMA est une réglementation préparée depuis plusieurs années, Apple n’était donc pas dans une situation où ce changement était imprévisible
Le conflit entre l’argument du faible usage et les perspectives de croissance des PWA
- Apple affirme que l’impact de cette réduction fonctionnelle est limité en raison du faible usage des web apps sur l’écran d’accueil
- Pourtant, Apple avait auparavant ajouté des fonctionnalités pour que les PWA se comportent davantage comme des apps natives et puissent être distribuées facilement hors de l’App Store
- Les perspectives du marché des PWA pointent dans une direction différente de l’argument d’Apple sur le faible usage
- les analystes estiment que le marché des PWA atteindra 10,44 milliards de dollars en 2027
- le taux de croissance annuel moyen serait de 31,9 %
- Si des moteurs de navigateur alternatifs peuvent rendre les PWA plus utiles, les web apps pourraient devenir une menace directe pour l’activité de l’App Store
- Apple n’a pas répondu séparément aux demandes de commentaire sur sa décision concernant les PWA et a choisi de publier son explication sur le site web consacré au DMA
1 commentaires
Commentaires sur Hacker News
Il a raison. Apple freine depuis des années le développement des web apps sur iOS et a empêché les web apps de concurrencer les apps natives de l’App Store afin de préserver sa commission de 30 %
Maintenant qu’Apple doit autoriser des moteurs de navigateur tiers, les web apps pourraient devenir bien plus puissantes, mais Apple refuse de l’accepter et a choisi de désactiver une fonctionnalité utile à tout le monde
Cela risque de se retourner contre eux, et dégrader son propre produit pour embêter des concurrents ne fait qu’alimenter davantage le ressentiment des utilisateurs, des entreprises, des développeurs et des législateurs. Leur proposition de conformité au Digital Markets Act est presque de la non-conformité, et le DMA exige une interopérabilité libre alors qu’Apple a imposé des frais très anticoncurrentiels. Si cela disparaît, les développeurs pourront distribuer librement les apps natives qu’ils veulent, et à ce stade beaucoup migreront probablement vers d’autres app stores
Les gens vont simplement sur l’App Store télécharger l’app d’un site web au hasard, et même si ce n’est qu’une app navigateur qui affiche le site, ça leur est égal. Pour qu’un boycott d’Apple se produise, il faudrait supprimer quelque chose qui importe réellement aux gens
Alors même que je savais que cette fonction existait, et que j’ai même déjà écrit du code qui la prend en charge, il m’a fallu presque 5 minutes pour trouver le bouton. Le cacher dans la feuille de partage est vraiment idiot
Apple a été à l’origine de nombreuses fonctionnalités web qui rendent le web plus proche des apps natives, en rédigeant parfois les spécifications ou en les adoptant avant les autres. Des choses comme backdrop-filter, position: sticky, les points d’ancrage CSS contribuent bien davantage à donner aux sites web un aspect d’app native que des fonctions comme WebMIDI
Les réactions récentes liées au DMA relèvent souvent d’une conformité de mauvaise foi et d’une certaine mesquinerie, mais je ne pense pas que la suppression des favoris d’écran d’accueil sans Chrome en fasse partie. Ils ont plutôt interprété la réglementation de manière stricte et, n’étant pas très attachés à cette fonction, l’ont simplement supprimée
Apple semble avoir, pour la plateforme web, une philosophie et des priorités différentes de celles de Chrome, en mettant davantage l’accent sur la protection de la vie privée, les performances et l’efficacité
Dans les commentaires que j’ai lus, beaucoup semblent souhaiter que le DMA impose une interopérabilité gratuite, mais je ne sais pas si c’est réellement ce qu’il dit. Au contraire, il semble permettre assez explicitement aux gatekeepers de continuer à facturer l’accès
Le considérant 62 commence par : « pour les magasins d’applications logicielles, les moteurs de recherche en ligne et les services de réseaux sociaux en ligne inclus dans la décision de désignation, le contrôleur d’accès devrait publier et appliquer des conditions générales d’accès équitables, raisonnables et non discriminatoires », donc ce passage concerne les app stores
Le deuxième paragraphe commence par : « les prix ou autres conditions générales d’accès devraient être considérés comme inéquitables s’ils entraînent un déséquilibre des droits et obligations imposés aux utilisateurs professionnels, procurent au contrôleur d’accès un avantage disproportionné par rapport au service fourni aux utilisateurs professionnels par le contrôleur d’accès, ou désavantagent les utilisateurs professionnels dans la fourniture des mêmes services ou de services similaires à ceux du contrôleur d’accès »
Pour moi, cette formulation semble indiquer qu’au minimum la possibilité de facturer des frais est envisagée. Je serais curieux qu’on m’indique où https://eur-lex.europa.eu/eli/reg/2022/1925/oj exige une « interopérabilité gratuite »
Si vous parlez de l’article 6.7, je ne suis pas d’accord. À mon avis, cela ne traite que de choses comme l’accès aux SDK, les spécifications des ports matériels, ou la capacité à faire des appels système comparables à ceux des applications du gatekeeper
L’article 6.7 dit : « le contrôleur d’accès doit permettre aux fournisseurs de services et de matériel informatique une interopérabilité effective et gratuite avec, ainsi qu’un accès aux fins d’interopérabilité, aux mêmes fonctionnalités matérielles et logicielles accessibles ou contrôlées via le système d’exploitation ou l’assistant virtuel figurant dans la décision de désignation au titre de l’article 3, paragraphe 9, au même niveau que celui disponible pour les services ou le matériel fournis par le contrôleur d’accès. Le contrôleur d’accès doit également permettre aux utilisateurs professionnels et aux fournisseurs alternatifs de services fournis conjointement avec des services de plateforme essentiels, ou à l’appui de ceux-ci, une interopérabilité effective et gratuite avec, ainsi qu’un accès aux fins d’interopérabilité, aux mêmes fonctionnalités du système d’exploitation, du matériel ou du logiciel disponibles ou utilisées dans la fourniture par le contrôleur d’accès de tels services, que ces fonctionnalités fassent ou non partie du système d’exploitation »
Mais avec ce genre de mesures et la direction que prend Apple avec SwiftUI, cela me redonne plutôt envie de m’intéresser aux web apps
Du point de vue d’Apple, il est extrêmement pratique que les fonctions de sécurité et les comportements anticoncurrentiels se recoupent
Quand quelqu’un dit « je n’aime pas l’enfermement propriétaire », Apple retourne immédiatement cela en « donc tu n’aimes pas la sécurité ? »
Mais c’est souvent une fausse alternative fabriquée par Apple. Qu’Apple examine et rejette des apps pour bloquer les arnaques et les malwares, très bien, mais l’entreprise mélange cela avec le rejet d’apps simplement parce qu’elles ont utilisé le mot « Android », ou avec la mise en avant du type de curation qu’elle préfère
L’interface d’abonnement native en un clic est sûre et pratique pour l’utilisateur, mais grâce au duopole mobile et au contrôle de la plateforme, Apple peut facturer autant qu’elle le souhaite. Apple parle comme si autoriser d’autres processeurs de paiement revenait à envoyer les gens vers des sites douteux où il serait impossible d’annuler un abonnement ou d’obtenir un remboursement, mais là aussi c’est une fausse alternative créée par Apple. On pourrait exiger des processeurs de paiement alternatifs qu’ils s’intègrent à l’API de gestion des abonnements iOS, et Apple prend déjà en charge PayPal en backend
Ici, c’est pareil : l’idée qu’ouvrir des API internes à des tiers sans garde-fous serait dangereux joue bien trop en faveur d’Apple. Mais il n’est pas nécessaire d’exécuter des navigateurs tiers sans sandbox, ni de laisser n’importe quelle app créer librement des icônes sur l’écran d’accueil. L’ajout à l’écran d’accueil est déjà une action utilisateur via la feuille de partage, arbitrée par l’OS. Les navigateurs sont de toute façon censés rester dans une sandbox, et les web apps étaient déjà autorisées à s’exécuter en plein écran
Ce n’est pas seulement l’absence d’une fonctionnalité précise. Apple soutient depuis des années que l’App Store n’est pas indispensable et que tout le monde peut simplement créer une web app. Ce n’était déjà pas totalement vrai à cause des limitations de Safari, mais maintenant cela devient une farce
« À la place, l’app frauduleuse LassPass tente de pousser l’utilisateur à souscrire un compte “pro” à 2 $/mois, 10 $/an, ou 50 $ à vie. Pour une app frauduleuse, le prix est en fait bas. Beaucoup d’apps douteuses essaient plutôt de facturer quelque chose comme 10 $ par semaine »
Et il affirmait aussi, sans pouvoir le savoir, que « cela ne semble pas avoir été créé pour voler des identifiants LastPass ». L’ensemble du texte donnait l’impression de dire : « Oui, c’est mauvais et ça n’aurait pas dû arriver, mais ce n’est pas si grave. Pourquoi vous acharnez-vous autant sur Apple ? »
Apple pense-t-il que ce genre de manœuvre va déclencher un rejet de la réglementation européenne ?
Chaque fois que je lis une nouvelle absurdité de ce genre, mon sang ne fait qu’un tour, et mon attitude ne fait que se durcir envers Apple et les autres géants anticoncurrentiels
Ce qui devrait vraiment nous mettre hors de nous, ce sont les choses qu’on ne peut pas facilement éviter dans la vie. Au fond, ce ne sont que des téléphones et des ordinateurs, et j’y gaspille une passion totalement vaine
J’aimerais que ceux qui se plaignent d’Apple cessent de geindre et fassent une grève en arrêtant de développer pour le matériel Apple
Mieux encore, ils pourraient fabriquer eux-mêmes leur propre matériel, censé être libéré de tout ce lourd bagage logiciel, et beaucoup des entreprises qui se plaignent valent des milliards de dollars, donc elles en auraient les moyens
Bien sûr, elles ne le feront pas, parce qu’elles veulent de l’argent elles aussi, comme Apple. Mais si Spotify, Epic et d’autres cessaient de prendre en charge les appareils iOS, Apple envisagerait peut-être de changer d’attitude
Si les développeurs et les utilisateurs passaient sur Android, Apple changerait. Android est-il vraiment si mauvais qu’il faille être forcé d’utiliser iOS ?
C’est comme le fait que personne n’aime conserver cinq abonnements pour accéder à Netflix, HBO, Prime, Disney et Hulu. Même sans monopole, avoir déjà un duopole relève du miracle
Ces gens n’assument pas la moindre responsabilité et continuent simplement à acheter cette foutue camelote
Pour moi, l’essentiel est dans la phrase « maintenant, les web apps se comportent comme des signets de sites web, sans stockage local, badges, notifications ni prise en charge des fenêtres dédiées »
L’accès depuis l’écran d’accueil n’a pas été complètement bloqué. Pour mes web apps simples, je peux m’en sortir sans notifications ni stockage local
Mais beaucoup de gens ont besoin de Progressive Web Apps, donc je comprends que ce changement leur paraisse particulièrement malveillant
C’est clairement une mesquinerie flagrante de la part d’Apple, donc si l’on veut soutenir un logiciel équitable et bienveillant, il est peut-être temps de changer le matériel qu’on a dans la poche
Un site web en mode autonome est une “app” web, mais si un site ne peut pas faire disparaître la barre du navigateur dans Safari, même en utilisant toutes les fonctionnalités web modernes, alors les web apps sont impossibles dans Safari. Ce n’est qu’un raccourci vers un site web en mode onglet
En plus, on ne sait toujours pas quelles fonctionnalités web Apple prévoit d’interdire sur les sites, ni si elles seront aussi interdites dans les navigateurs concurrents
On ne sait pas non plus s’il reste possible d’avoir des sites hors ligne utilisant le cache des service workers. D’après certains bêta-testeurs, cela semble avoir été désactivé
Personnellement, le stockage local n’est peut-être pas important, mais il faut réfléchir à quel point cela désavantage le développement web si Apple peut effacer le stockage local sans l’accord de l’utilisateur, comme dans un onglet Safari
L’absence de garantie pour l’avenir est l’un des plus gros problèmes. La programmation web est une stratégie que les entreprises choisissent aujourd’hui pour pouvoir déployer de bonnes web apps dans 2 ou 3 ans
En supposant qu’Apple ait laissé les PWA inchangées, c’est-à-dire codées en dur dans Safari, est-ce que Mozilla ou Microsoft n’auraient pas immédiatement poursuivi Apple ou soulevé le problème pour violation du DMA, au motif qu’ils ne pourraient pas exécuter leur propre moteur de navigateur depuis les icônes ajoutées par l’utilisateur à l’écran d’accueil ?
Dans ce cas, maintenir les PWA existantes telles quelles aurait exposé Apple à un risque d’amendes astronomiques dans l’UE, non ?
Si les développeurs iOS étaient à ce point nuls, il suffisait de payer des développeurs macOS pour implémenter les changements nécessaires pendant le week-end. Les deux systèmes d’exploitation sont de la famille Unix, macOS en est largement capable, et Apple a eu des années pour le faire
Si Apple veut jouer la carte du « c’est trop difficile », alors, conformément au DMA, l’entreprise doit prouver pourquoi cela représente une charge si importante. Or ce n’est pas le cas en réalité, donc elle ne peut pas le prouver. Elle aurait quand même pu discuter avec l’UE pour obtenir une exception afin de ne pas casser les web apps Safari tant que tous les navigateurs web ne seraient pas prêts à utiliser des web apps sur iOS
Ce qu’Apple a réellement fait, c’est casser toutes les web apps iOS qui ne fonctionnaient que dans Safari, puis se battre encore un an contre l’UE avant, si elle perd, de les réautoriser
Peut-on vraiment dire que ce n’est pas malveillant ? Ils osent faire ça précisément parce que le nombre d’utilisateurs de web apps est faible aujourd’hui
Affirmer qu’il est difficile de couvrir tous les cas en quelques mois ne fait que fabriquer des excuses pour ce retard prolongé
Imaginons que vous vouliez créer un petit tableau de bord pour home server, affichable en plein écran sur un iPhone. Si vous vivez dans l’UE, comment êtes-vous censé l’ajouter à l’écran d’accueil ?
Comme il s’agit d’un serveur local, cela ne passerait pas la revue, donc impossible de le publier sur l’App Store même si vous le vouliez. Même un build local de débogage expire au bout d’environ une semaine. Que peut-on faire dans ce cas ?
Ce n’est pas pour défendre Apple. Je suis opposé à beaucoup de décisions qui limitent ce que je peux faire avec le matériel que j’ai acheté, y compris la politique « WebKit only ». Malgré tout, comme j’ai une certaine compréhension de l’état actuel des produits Apple, j’ai un peu de mal à compatir avec quelqu’un qui achète un iPhone en espérant ce genre d’interopérabilité sur mesure
Les utilisateurs non techniques ont bien moins de chances de vouloir ce niveau de personnalisation, et les utilisateurs techniques sont censés être mieux informés
Cela dit, j’aimerais vraiment que ça change. Ce serait bien de pouvoir raisonnablement considérer qu’un matériel généraliste est effectivement utile pour des usages généralistes
Les PWA sont parfaites pour les applications privées ou internes. En Europe, il semble qu’un bon nombre de prestataires de santé utilisent des PWA pour fournir des soins aux patients. Apple est en train de casser ces apps et de faire détruire les données utilisateur stockées sans préavis
Après tout, ce n’est guère plus qu’un lien vers une page web
Je n’ai jamais implémenté de PWA et je ne suis pas utilisateur Apple, donc il me manque peut-être du contexte. Cela dit, ça semblait être une bonne approche pour développer une app cross-platform simple
Si j’ai bien compris, une PWA ne s’ouvre plus en plein écran et n’a plus l’apparence d’une app native ; elle s’ouvre désormais comme un favori dans le navigateur
Mais si ce n’est qu’une page web, ça devrait quand même continuer à « fonctionner », non ?
Si Apple a cassé l’API de notifications, alors les notifications ne marcheront plus, mais beaucoup de sites les utilisent. Par exemple, les pop-ups d’activation des notifications desktop sur WhatsApp Web sont-ils eux aussi cassés maintenant ?
L’absence de stockage local, ça veut dire
sessionStorage/localStoragede JavaScript ? Si ça casse, énormément de sites web vont être affectés. Le stockage des cookies, ce n’est pas quelque chose qu’on peut casser à la légère, non ?Une PWA n’aura peut-être plus l’air d’une app bien polie, mais pour un simple tableau de bord personnel, cela ne semble pas poser un gros problème
Les API HTML/JavaScript autorisent le plein écran
Apple a déclaré qu’« une web app malveillante peut lire les données d’autres apps et accéder, avec le consentement de l’utilisateur, à la caméra, au micro et à la localisation », et explique donc qu’après avoir dû autoriser des moteurs de navigateur alternatifs en raison des exigences du DMA, l’entreprise a dégradé l’expérience des web apps iOS pour les utilisateurs européens afin de prévenir les risques
Pourtant, l’accès à la caméra, au micro et à la localisation des utilisateurs reste toujours possible. C’est assez curieux
Il y aura sûrement quelqu’un pour croire à ce raisonnement
À ma connaissance, Epic ne crée pas de PWA, donc cela ressemble davantage à une critique générale lancée contre Apple
Malgré la position dominante d’Apple, je comprends l’envie de réduire la surface d’attaque et de supprimer une fonctionnalité que seule une infime minorité d’utilisateurs employait. Les PWA occupent une zone floue entre la web app classique et l’app complète. Une web app normale peut aussi, si je ne me trompe pas, être ajoutée en favori à l’écran d’accueil, mettre en cache des ressources avec les en-têtes HTTP E-Tag et Cache-Control, et disposer de
localStorageIl n’est pas clair quel est exactement l’avantage des PWA par rapport aux web apps classiques. Peuvent-elles recevoir quelque chose comme du push serveur permanent ? Et combien d’utilisateurs veulent réellement cela ?
Personnellement, je n’ai jamais utilisé ni créé de PWA. Si je veux cibler iOS natif ou Android, je lance un projet React Native comme n’importe quelle personne normale
J’aime autant que quiconque attaquer les pratiques monopolistiques d’Apple, mais dans ce cas précis, cela me semble exagéré. Les PWA sont une sorte d’enfant illégitime ambigu du développement web, et abandonner leur prise en charge pour simplifier le système d’exploitation et les API associées a du sens
C’est agaçant de voir la conversation toujours détournée par des gens qui ne sont pas en position de jeter la pierre, et de voir quelque chose qui n’aurait pas besoin d’être une controverse devenir une « controverse »