Publié dans Logiciel

73

L’Europe se penche sur l’arrêt des web apps dans iOS 17.4

Drapeaux de l’Union européenne

Comme nous l’indiquions récemment, Apple a décidé de faire sauter la possibilité d’installer des applications web (PWA) dans iOS avec la mise à jour 17.4 en Europe.

Selon Apple, cette décision a été prise pour deux raisons : elle est peu utilisée et il aurait été trop complexe de la préserver avec les changements envisagés. iOS 17.4 permet en effet aux éditeurs d’intégrer leur propre moteur de rendu dans leurs navigateurs. Pour Apple, remettre en place la même infrastructure pour ces moteurs que pour Safari réclamerait trop de temps vis-à-vis du bénéfice.

Cette suppression n’est pas passée inaperçue. La Commission européenne a confirmé au Financial Times qu’elle se penchait sur la question. Elle a envoyé une série de questions à des développeurs pour recueillir leur avis sur le sujet. Apple aussi a reçu des questions, sans que l’on sache lesquelles.

Faisons remarquer qu’Apple est responsable en partie du peu d’utilisation fait des PWA sur iOS. Les notifications et leurs badges sur les icônes des PWA ne sont arrivés en effet qu’avec iOS 16.4.

Rappelons également que sans PWA, certains services ne peuvent plus fonctionner sur iOS, dont les services de jeux en streaming GeForce Now et Xbox Game Pass.

73

Tiens, en parlant de ça :

Le Slip français se fait trouer : 1,5 million d’emails et des données de 696 144 clients dérobés ?

C'est la fête du slip ! (© Fred42)

16:07 Sécu 19
Cadran de coffre-fort

Après l’affaire XZ Utils, la sécurité des projets open source en question

Nudes in bio

15:47 SoftSécu 7

Samsung dépasse les 10 Gb/s avec sa mémoire LPDDR5X

SK hynix va-t-il tenter la LPDDR5MT (Mega Turbo) ?

10:51 Hard 5
Le brief de ce matin n'est pas encore là

Partez acheter vos croissants
Et faites chauffer votre bouilloire,
Le brief arrive dans un instant,
Tout frais du matin, gardez espoir.

73

Fermer

Commentaires (73)


Précision : les PWA ont été inventé par Google (utilisable avec Chrome), puis adopté par Microsoft.

Ceci expliquant en partie cela.
De mémoire Apple avait implémenté un système similaire avant, avec la première version de iOS, mais ça n'avait pas pris
Bien joué de la part d'Apple: la société obéit au DMA tout en renforçant les clôture de son jardin, surtout pour les jeux.

Ca va être dur pour l'UE d'imposer à Apple de rétablir les PWA sachant que c'est officiellement encore [en draft]:(https://www.w3.org/TR/appmanifest) et que c'est loin d'être massivement utilisé. Et puis il faut bien avouer que PWA c'est une arnaque technico-commerciale de Google visant à faire passer des pages web pour des apps natives.
Alors pour le coup, au contraire, je trouves que les PWA ne sont pas DU TOUT une arnaque !
J'ai le cas de clients qui ont besoin/envie d'une application pour leurs utilisateurs, mais qui n'ont pas le budget pour une appli native, ou qui ont des besoins qui vont à l'encontre des conditions des Stores (exemple : ils ont des services qu'ils peuvent mettre en place via de la configuration côté serveur. Comme une appli sur iOS doit pouvoir gérer TOUT le fonctionnel, et que le fonctionnel est ici géré côté serveur, on est bloqués).
Ils ont juste besoin d'une icône sur l'écran d'accueil et de la gestion des notifications : c'est justement ce à quoi servent les PWA.

Ici, on est bien dans un enfermement d'Apple.

potn

Alors pour le coup, au contraire, je trouves que les PWA ne sont pas DU TOUT une arnaque !
J'ai le cas de clients qui ont besoin/envie d'une application pour leurs utilisateurs, mais qui n'ont pas le budget pour une appli native, ou qui ont des besoins qui vont à l'encontre des conditions des Stores (exemple : ils ont des services qu'ils peuvent mettre en place via de la configuration côté serveur. Comme une appli sur iOS doit pouvoir gérer TOUT le fonctionnel, et que le fonctionnel est ici géré côté serveur, on est bloqués).
Ils ont juste besoin d'une icône sur l'écran d'accueil et de la gestion des notifications : c'est justement ce à quoi servent les PWA.

Ici, on est bien dans un enfermement d'Apple.
Invoquer des raisons comme "pas le budget" ou "aller à l'encontre des conditions des Stores" ca montre bien que PWA n'est pas une réponse à un problème technique. C'est une réponse à un problème commercial.
Modifié le 28/02/2024 à 10h38

Historique des modifications :

Posté le 28/02/2024 à 10h37


Invoquer des raisons comme "pas le budget" ou "aller à l'encontre des conditions des Stores" ca montre bien que PWA n'est pas un réponse à un problème technique. C'est une réponse à un problème commercial.

127.0.0.1

Invoquer des raisons comme "pas le budget" ou "aller à l'encontre des conditions des Stores" ca montre bien que PWA n'est pas une réponse à un problème technique. C'est une réponse à un problème commercial.
Ya moins de maintenance sur une PWA sur le papier, ça c'est une raison technique, non ?

marba

Ya moins de maintenance sur une PWA sur le papier, ça c'est une raison technique, non ?
Ne soyons pas hypocrite, le (relatif) succès de PWA c'est que ca permet d'outrepasser les contraintes de l'App-Store, qu'elles soient régulatoires ou financières. C'est d'ailleurs pour cela que Apple veut les virer.

127.0.0.1

Ne soyons pas hypocrite, le (relatif) succès de PWA c'est que ca permet d'outrepasser les contraintes de l'App-Store, qu'elles soient régulatoires ou financières. C'est d'ailleurs pour cela que Apple veut les virer.
Firefox OS (en avance sur son temps) n'aurait jamais existé si cette technologie n'avait pas quelque chose de prometteur.

127.0.0.1

Ne soyons pas hypocrite, le (relatif) succès de PWA c'est que ca permet d'outrepasser les contraintes de l'App-Store, qu'elles soient régulatoires ou financières. C'est d'ailleurs pour cela que Apple veut les virer.
Ça ne permet pas QUE ça, mais c'est sûr que c'est un des gros intérêts des PWA.
Techniquement, ça permet :
- une maintenance simplifiée par rapport à une application native
- des mises à jour maîtrisées (c'est fait côté serveur, pas client)
- une compatibilité avec Android et (avant) iOS, et les navigateurs, pour le MÊME CODE
- une installation bien plus simple que ce qu'on voit sur les sites actuels avec "utilisez plutôt l'application" => lien vers l'appli sur le Store => installation => reprise de la navigation au début mais depuis l'application cette fois-ci : une PWA, on clique sur le bouton "installer" affiché sur la page et c'est tout


Bref, c'est pas la panacée non plus car on reste limités par les fonctionnalités prises en charge par les PWA et les navigateurs qui la font tourner, mais pour beaucoup de cas, ça peut être suffisant.
Si iOS avait pris en charge ce type d'application depuis le début des PWA, on en aurait probablement partout.

127.0.0.1

Invoquer des raisons comme "pas le budget" ou "aller à l'encontre des conditions des Stores" ca montre bien que PWA n'est pas une réponse à un problème technique. C'est une réponse à un problème commercial.
Pour la raison "aller à l'encontre des conditions des Stores", je suis d'accord que c'est une réponse technique à un problème commercial.
Par contre, pour le "pas le budget", j'ai l'impression que tu n'as pas en tête la différence de prix qu'il peut y avoir entre la mise en place et la maintenance d'une application native pour Android/iOS (même avec un framework type Ionic), et la même chose avec une PWA.
Cette différence de prix est très importante pour des PME ou des groupes plus ou moins gros mais qui n'ont pas un grand budget.

Et encore, c'est sans parler du fait que parfois les PWA répondent mieux au besoin du client que l'application native.

potn

Pour la raison "aller à l'encontre des conditions des Stores", je suis d'accord que c'est une réponse technique à un problème commercial.
Par contre, pour le "pas le budget", j'ai l'impression que tu n'as pas en tête la différence de prix qu'il peut y avoir entre la mise en place et la maintenance d'une application native pour Android/iOS (même avec un framework type Ionic), et la même chose avec une PWA.
Cette différence de prix est très importante pour des PME ou des groupes plus ou moins gros mais qui n'ont pas un grand budget.

Et encore, c'est sans parler du fait que parfois les PWA répondent mieux au besoin du client que l'application native.
Une app native permet de faire tout ce que fait une PWA... certes pour un cout plus élevé.

Mais d'un point de vue strictement technique, Apple peut affirmer qu'un éditeur peut proposer à ses clients les mêmes fonctions avec ou sans PWA.

On est tous d'accord que ce n'est pas "fair-play" de la part d'Apple de vire PWA. Mais c'est bien joué stratégiquement: ca permet a Apple de respecter le DMA tout en verrouillant davantage sa plateforme.

127.0.0.1

Une app native permet de faire tout ce que fait une PWA... certes pour un cout plus élevé.

Mais d'un point de vue strictement technique, Apple peut affirmer qu'un éditeur peut proposer à ses clients les mêmes fonctions avec ou sans PWA.

On est tous d'accord que ce n'est pas "fair-play" de la part d'Apple de vire PWA. Mais c'est bien joué stratégiquement: ca permet a Apple de respecter le DMA tout en verrouillant davantage sa plateforme.
Non, une application native ne peut pas faire tout ce que fait une PWA, pour la simple et bonne raison qu'une PWA est gérée côté serveur, là où une application native est gérée côté client.
Si tu veux ajouter une fonctionnalité à l'application native, il FAUT la mettre à jour. Mais surtout, pour qu'une application native puisse gérer toutes les fonctionnalités fournies par le serveur, il faut qu'elle intègre TOUTES les fonctionnalités du serveur. Or, il est inenvisageable de gérer côté client toute la diversité fonctionnelle des plugins qu'on peut ajouter à des serveurs comme Nextcloud ou Wordpress, par exemple.

Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉
Modifié le 29/02/2024 à 23h17

Historique des modifications :

Posté le 29/02/2024 à 23h17


Non, une application native ne peut pas faire tout ce sue fait une PWA, pour la simple et bonne raison qu'une PWA est gérée côté serveur, là où une application native est gérée côté client.
Si tu veux ajouter une fonctionnalité à l'application native, il FAUT la mettre à jour. Mais surtout, pour qu'une application nztive puisse gérer toutes les fonctionnalités fournies par le serveur, il faut qu'elle intègre TOUTES les fonctionnalités du serveur. Or, il est inenvisageable de gérer côté client toute la diversité fonctionnelle des plugins qu'on peut ajouter à des serveurs comme Nextcloud ou Wordpress, par exemple.

Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉

potn

Non, une application native ne peut pas faire tout ce que fait une PWA, pour la simple et bonne raison qu'une PWA est gérée côté serveur, là où une application native est gérée côté client.
Si tu veux ajouter une fonctionnalité à l'application native, il FAUT la mettre à jour. Mais surtout, pour qu'une application native puisse gérer toutes les fonctionnalités fournies par le serveur, il faut qu'elle intègre TOUTES les fonctionnalités du serveur. Or, il est inenvisageable de gérer côté client toute la diversité fonctionnelle des plugins qu'on peut ajouter à des serveurs comme Nextcloud ou Wordpress, par exemple.

Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉
Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉


Bien sur que ca serait absurde et de mauvaise foi de la part d'Apple de dire que c'est possible sans PWA.

Tout comme ca serait absurde et de mauvaise foi de la part des développeurs de dire que c'est impossible dans une application native.

Mais je parlais juste d'arguments sur le plan légal pour contrer/conforter la décision d'Apple.

127.0.0.1

Tu pourrais me rétorquer que c'est possible, même si très compliqué, mais alors je te répondrais qu'il est possible de faire ton propre iOS qui gère les PWA, et là on tomberait dans l'absurde ou la mauvaise fois. 😉


Bien sur que ca serait absurde et de mauvaise foi de la part d'Apple de dire que c'est possible sans PWA.

Tout comme ca serait absurde et de mauvaise foi de la part des développeurs de dire que c'est impossible dans une application native.

Mais je parlais juste d'arguments sur le plan légal pour contrer/conforter la décision d'Apple.
Tout comme ca serait absurde et de mauvaise foi de la part des développeurs de dire que c'est impossible dans une application native.


Tu parles bien ici d'implémenter toutes les fonctionnalités de toutes les extensions d'un outils type Nextcloud, par exemple ?
La seule solution viable que j'y voit est d'intégrerune webview dans l'appli... Mais à ce moment là, ce n'est plus vraiment l'appli native qui "gère", mais plutôt le navigateur qui tourne en son sein.

Après, d'un point de vue légal, je ne sais pas du tout ce que ça peut donner. J'espère juste qu'Apple va se prendre une grosse claque et devoor accepter les PWA de nouveau pour éviter de verrouiller entièrement ses utilisateurs sur l'App Store.

potn

Tout comme ca serait absurde et de mauvaise foi de la part des développeurs de dire que c'est impossible dans une application native.


Tu parles bien ici d'implémenter toutes les fonctionnalités de toutes les extensions d'un outils type Nextcloud, par exemple ?
La seule solution viable que j'y voit est d'intégrerune webview dans l'appli... Mais à ce moment là, ce n'est plus vraiment l'appli native qui "gère", mais plutôt le navigateur qui tourne en son sein.

Après, d'un point de vue légal, je ne sais pas du tout ce que ça peut donner. J'espère juste qu'Apple va se prendre une grosse claque et devoor accepter les PWA de nouveau pour éviter de verrouiller entièrement ses utilisateurs sur l'App Store.
Apple désamorce (un peu) la situation des PWA avec l'Europe. Bon, ca oblige a avoir un navigateur webkit et de ne pas upgrader en IOS 17.4 :D
Apple has backtracked and says that ‌Home Screen‌ web apps that use WebKit in the EU will continue to function as expected upon the release of iOS 17.4.


https://www.macrumors.com/2024/03/01/apple-walks-back-decision-to-disable-eu-web-apps/
Modifié le 02/03/2024 à 13h20

Historique des modifications :

Posté le 02/03/2024 à 13h20


Apple désamorce (un peu) la situation des PWA avec l'Europe. Bon, ca oblige a voir un navigateur webkit et de ne pas upgrader en IOS 17.4 :D

Apple has backtracked and says that ‌Home Screen‌ web apps that use WebKit in the EU will continue to function as expected upon the release of iOS 17.4.


https://www.macrumors.com/2024/03/01/apple-walks-back-decision-to-disable-eu-web-apps/

127.0.0.1

Apple désamorce (un peu) la situation des PWA avec l'Europe. Bon, ca oblige a avoir un navigateur webkit et de ne pas upgrader en IOS 17.4 :D
Apple has backtracked and says that ‌Home Screen‌ web apps that use WebKit in the EU will continue to function as expected upon the release of iOS 17.4.


https://www.macrumors.com/2024/03/01/apple-walks-back-decision-to-disable-eu-web-apps/
Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.


De ce que je comprends, même en 17.4, ça devrait fonctionner.
En gros, j'ai l'impression que Apple fait machine arrière toute. 🎉
Personnellement, j'ai toujours trouvé que ça marchait très mal les PWA, ça peut être une raison pour laquelle ils ne gardent pas ça. En tout cas sous Android+Firefox c'est pas terrible : ça recharge tout le temps la page sans la garde en cache et donc c'est bien plus lent qu'une application native (mon téléphone est lent et un peu ancien).
Perso j’utilise plusieurs PWA que je développe pour accéder à mes services (perso). C’est transparent par rapport à un app normale !
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !
Je vais être dégoûté quand elles vont disparaître de mon téléphone…
Modifié le 28/02/2024 à 09h38

Historique des modifications :

Posté le 28/02/2024 à 09h37


Perso j’utilise plusieurs PWA que j’ai développe pour accéder à mes services (perso). C’est transparent par rapport à un app normale !
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !

Posté le 28/02/2024 à 09h37


Perso j’utilise plusieurs PWA que je développe pour accéder à mes services (perso). C’est transparent par rapport à un app normale !
C’est juste qu’il faut que le dev fasse de la gestion de cache, etc. Parce que ça peut très bien fonctionner hors ligne une PWA !

Il faut que la PWA soit bien développée, aussi.
Ça revient au même que de dire que PHP c'est nul parce que plein de développeurs codent avec leurs pieds...
Idem, c'est beaucoup trop lent, je n'utilise pas.
Y'a moyen de participer à la demande d'avis de la Commission ?
Pas directement, mais tu peux commencer ici :
https://open-web-advocacy.org/apple-attempts-killing-webapps/

Boulonais

Pas directement, mais tu peux commencer ici :
https://open-web-advocacy.org/apple-attempts-killing-webapps/
Merci du lien, je viens de la signer au nom de Next.

Boulonais

Pas directement, mais tu peux commencer ici :
https://open-web-advocacy.org/apple-attempts-killing-webapps/
Merci pour le lien ! 😊
Je vais sûrement dire une bêtise car entre autres, cela date du lancement du premier iPhone (2007) mais à l'époque, Steve Jobs était contre les applications natives et indiquait qu'il suffisait de faire une application sur un site web. Ne serait pas là la définition basique d'une web app ?
S.Jobs proposait une web app traditionnelle = navigateur + web2.0 + ajax.

Pas d'une PWA qui s'installe, qui a son stockage en local et qui peut s'exécuter hors-ligne.

Citation:
"The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone."


.

127.0.0.1

S.Jobs proposait une web app traditionnelle = navigateur + web2.0 + ajax.

Pas d'une PWA qui s'installe, qui a son stockage en local et qui peut s'exécuter hors-ligne.

Citation:
"The full Safari engine is inside of iPhone. And so, you can write amazing Web 2.0 and Ajax apps that look exactly and behave exactly like apps on the iPhone."


.
Merci pour l'explication.
Pour qu'une PWA fonctionne en local sans internet, ça veut dire que tout son code source est dispo en clair sur la machine ?
En théorie, rien n'empêche que le code soit du wasm et pas du js.
Mais je parierais que c'est souvent du js :)

Donc le code js est "en clair" autant qu'il l'est dans une web-app traditionnelle, ou dans une appli électron.
Et comme c'est écrit avec des outils/frameworks, c'est de mon point de vue de vieux con peu lisible.
Modifié le 28/02/2024 à 12h04

Historique des modifications :

Posté le 28/02/2024 à 12h04


En théorie, rien n'empêche que le code soit du wasm et pas du js.
Mais je parierais que c'est souvent du js :)

Donc le code js est "en clair" autant qu'il l'est dans une web-app traditionnelle, ou dans une appli électron.
Et cu que c'est écrit avec des outils/frameworks, c'est de mon point de vue peu lisible.

Le site web met en cache en avance des pages/contenu image/vidéo dans le storage local que lui permet le PWA.
Au delà des aspects techniques, il peut être intéressant de s'interroger sur le "droit de regard" que peut avoir une institution comme l'Europe sur les fonctionnalités proposées.

De nombreux services s'arrêtent, pour de multiples raisons (fermeture de la société, pas rentable, etc.). On l'a vu ces dernières années, les opérateurs qui se lancent dans la domotique et qui arrêtent par exemple. Sony qui a vendu explicitement sa PS3 avec l'option OtherOS qui a ensuite été annulé unilatéralement, etc. Je n'ai pas souvenir que dans ces cas là, que la commission européenne soit intervenue.

Je ne dis pas ça pour défendre Apple (j'aime pas leurs produits et ne les utilise pas :p). Je m'étonne juste que parce que c'est Apple qui arrête un service, on se penche sur son cas (surtout pour un service pas indispensable). Non parce que bon, une personne qui a équipé sa maison avec Orange se retrouve avec plein d'objets rendus inutilisables à cause de l'arrêt du service, cela n'a pas vraiment ému la commission européenne...

A quel point la commission européenne peut-elle obliger une entreprise à faire évoluer un produit plutôt que de l'arrêter ? Que l'Europe puisse obliger une entreprise à se mettre en conformité avec la réglementation, c'est normal. Mais cette mise en conformité ne passe pas forcément par une évolution, cela peut être un arrêt du service.

Vous avez 4h xD
Apple a expliqué que cet abandon était lié au DMA qui imposait de pouvoir utiliser un autre navigateur que Safari sur les iPhones.
La Commission est donc en droit de vérifier si en faisant cela, Apple ne contourne pas le DMA.
On verra bien ce qu'elle dira à la fin.

fred42

Apple a expliqué que cet abandon était lié au DMA qui imposait de pouvoir utiliser un autre navigateur que Safari sur les iPhones.
La Commission est donc en droit de vérifier si en faisant cela, Apple ne contourne pas le DMA.
On verra bien ce qu'elle dira à la fin.
Ca je suis d'accord. Ce que je veux dire, c'est que le DMA impose des conditions pour éviter qu'une entreprise ayant une position dominante position de contrôleur d'accès ne pipe le jeu en imposant des conditions inéquitables (je simplifie, mais je ne suis pas très loin non plus).

En retirant les PWA, tout le monde est mis à la même enseigne. Apple n'a pas plus d'avantage que les autres.

C'est "juste" les utilisateurs qui perdent une fonctionnalité. Une fonctionnalité non indispensable / non essentielle (et peu utilisée d'après Apple).

fdorin

Ca je suis d'accord. Ce que je veux dire, c'est que le DMA impose des conditions pour éviter qu'une entreprise ayant une position dominante position de contrôleur d'accès ne pipe le jeu en imposant des conditions inéquitables (je simplifie, mais je ne suis pas très loin non plus).

En retirant les PWA, tout le monde est mis à la même enseigne. Apple n'a pas plus d'avantage que les autres.

C'est "juste" les utilisateurs qui perdent une fonctionnalité. Une fonctionnalité non indispensable / non essentielle (et peu utilisée d'après Apple).
Techniquement, en l'état de la proposition d'Apple, tout le monde est loin d'être à la même enseigne en ce qui concerne la distribution des apps, au vu des contraintes drastiques imposées par Apple dans sa proposition actuelle, tant sur les barrières à l'entrée d'un store alternatif que sur la facturation incompréhensible des apps qui ont le plus de téléchargements.
Si Apple décidait d'ouvrir vraiment leurs systèmes aux apps tierces sans contrôle ni contrepartie, la disparition des Webapps serait moins choquante. Ce n'est pas le cas ici.

Et pour rebondir sur ton point plus haut, j'ai du mal à voir en quoi maintenir les webapps est une contrainte quelconque pour Apple, d'autant plus qu'elles restent parfaitement supportées en dehors du territoire européen.
Sauf si un détail m'échappe, ça s'apparente complètement à une pratique anticoncurrentielle (de plus, s'agissant d'Apple).

Les ordinateurs personnels font tourner n'importe quelle application sans devoir payer l'éditeur de l'OS, pourquoi diable devrait-il en être autrement sur un mobile ?
C'est pas comme si Apple perdait de l'argent sur la vente de ses devices vendus à prix d'or.
A ce prix, je veux pouvoir être libre d'installer ce que je veux sans leur contrôle et leur "sécurité".

Ferd

Techniquement, en l'état de la proposition d'Apple, tout le monde est loin d'être à la même enseigne en ce qui concerne la distribution des apps, au vu des contraintes drastiques imposées par Apple dans sa proposition actuelle, tant sur les barrières à l'entrée d'un store alternatif que sur la facturation incompréhensible des apps qui ont le plus de téléchargements.
Si Apple décidait d'ouvrir vraiment leurs systèmes aux apps tierces sans contrôle ni contrepartie, la disparition des Webapps serait moins choquante. Ce n'est pas le cas ici.

Et pour rebondir sur ton point plus haut, j'ai du mal à voir en quoi maintenir les webapps est une contrainte quelconque pour Apple, d'autant plus qu'elles restent parfaitement supportées en dehors du territoire européen.
Sauf si un détail m'échappe, ça s'apparente complètement à une pratique anticoncurrentielle (de plus, s'agissant d'Apple).

Les ordinateurs personnels font tourner n'importe quelle application sans devoir payer l'éditeur de l'OS, pourquoi diable devrait-il en être autrement sur un mobile ?
C'est pas comme si Apple perdait de l'argent sur la vente de ses devices vendus à prix d'or.
A ce prix, je veux pouvoir être libre d'installer ce que je veux sans leur contrôle et leur "sécurité".
Techniquement, en l'état de la proposition d'Apple, tout le monde est loin d'être à la même enseigne en ce qui concerne la distribution des apps,


Je me limitais aux apps WPA. J'aurais du le préciser :chinois:
Et pour rebondir sur ton point plus haut, j'ai du mal à voir en quoi maintenir les webapps est une contrainte quelconque pour Apple, d'autant plus qu'elles restent parfaitement supportées en dehors du territoire européen.


Si j'ai bien compris :
- la question ne se pose pas en dehors du territoire européen, car il ne sera pas possible d'utiliser un autre moteur de rendu (cela sera obligatoirement WebKit)
- je pense que le problème que rencontre Apple, c'est que le moteur de rendu doit faire partie intégrante du coeur de son système d'exploitation (un peu comme le composant WebView en C#). Autrement dit : proposer un moteur alternatif revient à autoriser du code externe au coeur même de l'OS. Ce que refuse Apple d'un point de vue sécurité (et ça, je le comprends). L'autre solution serait de modifier le coeur de l'OS pour que le moteur de rendu ne soit plus au coeur du système. Ce qui nécessite une profonde réécriture de certaines parties, et le travail à accomplir pour cela est bien trop important par rapport à ce qui est demandé. Il est donc plus simple (et moins coûteux) de retirer une fonctionnalité afin de se conformer à la réglementation.

Bien évidemment, je peux me tromper, c'est juste comme ça que j'ai interprété leur communication (et en 30 ans de dev, je sais que ce qui semble parfois simple est en réalité complexe techniquement et inversement !)
A ce prix, je veux pouvoir être libre d'installer ce que je veux sans leur contrôle et leur "sécurité".


Ca existe : ça s'appelle Android (oki oki, je sors :p)

fdorin

Techniquement, en l'état de la proposition d'Apple, tout le monde est loin d'être à la même enseigne en ce qui concerne la distribution des apps,


Je me limitais aux apps WPA. J'aurais du le préciser :chinois:
Et pour rebondir sur ton point plus haut, j'ai du mal à voir en quoi maintenir les webapps est une contrainte quelconque pour Apple, d'autant plus qu'elles restent parfaitement supportées en dehors du territoire européen.


Si j'ai bien compris :
- la question ne se pose pas en dehors du territoire européen, car il ne sera pas possible d'utiliser un autre moteur de rendu (cela sera obligatoirement WebKit)
- je pense que le problème que rencontre Apple, c'est que le moteur de rendu doit faire partie intégrante du coeur de son système d'exploitation (un peu comme le composant WebView en C#). Autrement dit : proposer un moteur alternatif revient à autoriser du code externe au coeur même de l'OS. Ce que refuse Apple d'un point de vue sécurité (et ça, je le comprends). L'autre solution serait de modifier le coeur de l'OS pour que le moteur de rendu ne soit plus au coeur du système. Ce qui nécessite une profonde réécriture de certaines parties, et le travail à accomplir pour cela est bien trop important par rapport à ce qui est demandé. Il est donc plus simple (et moins coûteux) de retirer une fonctionnalité afin de se conformer à la réglementation.

Bien évidemment, je peux me tromper, c'est juste comme ça que j'ai interprété leur communication (et en 30 ans de dev, je sais que ce qui semble parfois simple est en réalité complexe techniquement et inversement !)
A ce prix, je veux pouvoir être libre d'installer ce que je veux sans leur contrôle et leur "sécurité".


Ca existe : ça s'appelle Android (oki oki, je sors :p)
Merci de ces précisions, c'est effectivement plus clair comme ça !

Je ne suis pas un spécialiste, mais si un autre moteur de rendu est géré dans un autre contexte comme celui d'une app, en quoi est-ce difficile de faire un autre type d'appel du même moteur de rendu en enlevant les barres du navigateur pour faire une PWA ?
Et pourquoi enlever si vite cette feature, alors que les moteurs de rendus alternatifs sont loin d'être prêts et opérationnels ?
Tout ceci me semble tout de même cousu de fil blanc...

Ferd

Merci de ces précisions, c'est effectivement plus clair comme ça !

Je ne suis pas un spécialiste, mais si un autre moteur de rendu est géré dans un autre contexte comme celui d'une app, en quoi est-ce difficile de faire un autre type d'appel du même moteur de rendu en enlevant les barres du navigateur pour faire une PWA ?
Et pourquoi enlever si vite cette feature, alors que les moteurs de rendus alternatifs sont loin d'être prêts et opérationnels ?
Tout ceci me semble tout de même cousu de fil blanc...
En même temps tu ne connais pas comment est gérée cette partie dans le code et les contraintes générées, de l'extérieur c'est souvent facile mais la réalité est toute autre.
L'objectif d'Apple n'est pas de supporter toutes les solutions du monde, c'est une entreprise commerciale avant tout :)

Ferd

Merci de ces précisions, c'est effectivement plus clair comme ça !

Je ne suis pas un spécialiste, mais si un autre moteur de rendu est géré dans un autre contexte comme celui d'une app, en quoi est-ce difficile de faire un autre type d'appel du même moteur de rendu en enlevant les barres du navigateur pour faire une PWA ?
Et pourquoi enlever si vite cette feature, alors que les moteurs de rendus alternatifs sont loin d'être prêts et opérationnels ?
Tout ceci me semble tout de même cousu de fil blanc...
Voilà l'explication d'Apple. Cliquer sur "Why don’t users in the EU have access to Home Screen web apps?" pour la lire.

Je trouve qu'ils ne justifient pas ce qu'ils affirment.


J'avais abordé le sujet dans un article précédent, je recopie ce que j'avais dit :
Il suffit qu'ils considèrent chaque web App comme une nouvelle appli et qu'ils lui créent un contexte isolé du Browser utilisé comme pour n'importe quelle app et leurs craintes seront vaines. En gros, le code du browser est unique mais les données et autorisations sont différentes pour chaque web app.


Mais je peux me tromper, je n'ai pas d'iPhone et ne connais pas le code d'Apple. Par contre, je sais qu'ils ont tout ce qu'il faut pour isoler le contexte d'une app (pas web app) d'une autre, donc je pense qu'ils pipeautent.
Modifié le 28/02/2024 à 16h16

Historique des modifications :

Posté le 28/02/2024 à 16h15


Voilà la justification d'Apple. Cliquer sur "Why don’t users in the EU have access to Home Screen web apps?" pour la lire.

Je trouve qu'ils ne justifient pas ce qu'ils affirment.


J'avais abordé le sujet dans un article précédent, je recopie ce que j'avais dit :

Il suffit qu'ils considèrent chaque web App comme une nouvelle appli et qu'ils lui créent un contexte isolé du Browser utilisé comme pour n'importe quelle app et leurs craintes seront vaines. En gros, le code du browser est unique mais les données et autorisations sont différentes pour chaque web app.


Mais je peux me tromper, je n'ai pas d'iPhone et ne connais pas le code d'Apple. Par contre, je sais qu'ils ont tout ce qu'il faut pour isoler le contexte d'une app (pas web app) d'une autre, donc je pense qu'ils pipeautent.

fred42

Voilà l'explication d'Apple. Cliquer sur "Why don’t users in the EU have access to Home Screen web apps?" pour la lire.

Je trouve qu'ils ne justifient pas ce qu'ils affirment.


J'avais abordé le sujet dans un article précédent, je recopie ce que j'avais dit :
Il suffit qu'ils considèrent chaque web App comme une nouvelle appli et qu'ils lui créent un contexte isolé du Browser utilisé comme pour n'importe quelle app et leurs craintes seront vaines. En gros, le code du browser est unique mais les données et autorisations sont différentes pour chaque web app.


Mais je peux me tromper, je n'ai pas d'iPhone et ne connais pas le code d'Apple. Par contre, je sais qu'ils ont tout ce qu'il faut pour isoler le contexte d'une app (pas web app) d'une autre, donc je pense qu'ils pipeautent.
Oui !
Si on regarde un peu plus loin d'ailleurs, quand on lit les justifications publiques d'Apple sur son opposition à l'ouverture du store sur toutes les procédures passées et en cours, l'énergie et la mauvaise foi déployée est très cohérente avec des arrangements potentiels avec la réalité technique sur les PWA.

J'ai un iPhone, j'en suis très content, mais je ne peux m'empêcher de ressentir une forme de dégout des pratiques d'Apple, et ce depuis une bonne décennie.
L'intérêt du client est passé loin derrière l'intérêt de l'actionnaire, et ça ne serait pas un problème en soi s'il existait des alternatives. Ce n'est pas le cas, et Apple n'est pas étranger à cet état de fait.
Il est plus que temps que le régulateur sévisse (je dirais même qu'il est un peu tard).

C'est aussi valable pour d'autres acteurs hégémoniques tech dans d'autres contextes, mais c'est un autre sujet.

Ferd

Merci de ces précisions, c'est effectivement plus clair comme ça !

Je ne suis pas un spécialiste, mais si un autre moteur de rendu est géré dans un autre contexte comme celui d'une app, en quoi est-ce difficile de faire un autre type d'appel du même moteur de rendu en enlevant les barres du navigateur pour faire une PWA ?
Et pourquoi enlever si vite cette feature, alors que les moteurs de rendus alternatifs sont loin d'être prêts et opérationnels ?
Tout ceci me semble tout de même cousu de fil blanc...
Je vais faire un parallèle avec le réseau (que tu connais mieux je crois ^^). Attention, c'est un parallèle, pas une analogie. L'objectif est de montrer l'impact qu'une méconnaissance d'un sujet peut avoir sur la compréhension même d'un problème.

Contexte de base : tu es un opérateur réseau, et pour des raisons de sécurité, toutes les IP de tes clients sont en IPv6, chacune munie d'une adresse IP publique.

Pour des raisons d'interopérabilité, compatibilité, (rajouter toute mention utile comme inutile), on t'impose de supporter l'IPv4, avec les mêmes "droits" ou "fonctionnalités". Sauf que voilà, ton architecture a été conçue autour de l'IPv6, pour profiter pleinement de toutes les possibilités offertes. En devant supporter l'IPv4, tu es :
1) obligé de mettre à jour toute une partie de ton infra
2) pour proposer les mêmes "droits" et "fonctionalités" quel que soit le protocole utilisé, tu décides de retirer les adresses IPv6 publiques (car tu ne peux pas fournir une IPv4 publique à tout le monde pour cause de pénurie), et tu vas donc restreindre les possibilités d'auto-hébergement (en même temps, ça concerne tellement peu de monde que ce n'est pas grave).

D'un point de vue du néophyte, ben c'est facile, l'IPv4 et l'IPv6 sont deux protocoles réseaux, je ne vois pas le problème.
D'un point de vue du connaisseur, c'est loin d'être aussi évident que ça car il voit toutes les implications que cela entraine. Le NAT n'a rien à voir entre l'IPv4 et l'IPv6. Il n'y a plus le souci de pénurie d'adresse, la gestion des MTU est différente, etc.

fdorin

Je vais faire un parallèle avec le réseau (que tu connais mieux je crois ^^). Attention, c'est un parallèle, pas une analogie. L'objectif est de montrer l'impact qu'une méconnaissance d'un sujet peut avoir sur la compréhension même d'un problème.

Contexte de base : tu es un opérateur réseau, et pour des raisons de sécurité, toutes les IP de tes clients sont en IPv6, chacune munie d'une adresse IP publique.

Pour des raisons d'interopérabilité, compatibilité, (rajouter toute mention utile comme inutile), on t'impose de supporter l'IPv4, avec les mêmes "droits" ou "fonctionnalités". Sauf que voilà, ton architecture a été conçue autour de l'IPv6, pour profiter pleinement de toutes les possibilités offertes. En devant supporter l'IPv4, tu es :
1) obligé de mettre à jour toute une partie de ton infra
2) pour proposer les mêmes "droits" et "fonctionalités" quel que soit le protocole utilisé, tu décides de retirer les adresses IPv6 publiques (car tu ne peux pas fournir une IPv4 publique à tout le monde pour cause de pénurie), et tu vas donc restreindre les possibilités d'auto-hébergement (en même temps, ça concerne tellement peu de monde que ce n'est pas grave).

D'un point de vue du néophyte, ben c'est facile, l'IPv4 et l'IPv6 sont deux protocoles réseaux, je ne vois pas le problème.
D'un point de vue du connaisseur, c'est loin d'être aussi évident que ça car il voit toutes les implications que cela entraine. Le NAT n'a rien à voir entre l'IPv4 et l'IPv6. Il n'y a plus le souci de pénurie d'adresse, la gestion des MTU est différente, etc.
Jouons !

- L'adaptation au changement est inhérent à toute entreprise, et c'est son quotidien - littéralement.
En permanence, nous devons nous adapter à des contraintes extérieures, et composer avec.
L'aléa peut venir des clients, des fournisseurs, des collaborateurs, de l'état, du propriétaire, des conjonctures économiques, de la banque, des taux directeurs, de l'actionnaire, de l'environnement, du matériel, de nouvelles normes, de la faute à pas de chance...
Avoir une contrainte de plus à gérer dans le contexte d'une boite comme Apple sur cette question de la régulation et des PWAs, bon, arrêtons de tourner autour du pot, c'est complètement mineur et gérable.
Le fond du refus n'est pas technique, et comme je le disais ailleurs, toute leur attitude autour du thème montre bien que le fond est économique et (anti-) concurrentiel.

- Ensuite, nous ne sommes pas un acteur hégémonique sur les telcos - personne ne l'est vraiment d'ailleurs, en mettant Orange de côté dans certains contextes (dont le GCBLO qui a fait parler de lui récemment par exemple).
Nous devons nous adapter ou mourir, car d'autres vont s'adapter et survivre.
Autrement dit, l'environnement au sens large contraint nos actions, et nous devons coller aux circonstances.
Nous avons déjà eu plein de questionnements autour de ces thèmes réseau, et les problèmes que nous rencontrons sont de diverses natures. Peu importe leur origine, notre job est de les régler, ou les gérer à minima.
Dans le cas d'Apple, c'est très différent.
C'est un cas rare où l'acteur a suffisamment de poids pour contraindre lui, à l'envi et à son seul profit l'ensemble des acteurs de sa sphère d'activité, qui est devenue indispensable aujourd'hui, et sans aucun contre-pouvoir. Grâce à sa position acquise de haute lutte et avec une dose certaine de travail, d'intelligence et de chance, Apple tord le bras à tous les acteurs qui se développent dans son sillage, dont les éditeurs d'apps.
C'est la stratégie du "tu vas faire quoi ?".
Apple considère qu'il fournit la plateforme aux devs, et qu'une partie de la valeur de leur travail leur revient, et que s'ils ne sont pas contents, ils n'ont qu'à mourir.
Tout le monde ferme sa gueule du coup, perd ses 20% de marge qui font la différence entre la vie et la survie (coucou Spotify), et il ne s'est rien passé de majeur pendant 10 ans.
Du point de vue d'Apple et des actionnaires, c'est un move rationnel.
Du point de vue général, à quel moment c'est normal de prendre 20% de la valeur de l'ensemble des services du service software portable mondial, quand il n'y a pas de plateforme alternative, que le matériel est déjà chèrement vendu, et que la valeur d'intermédiation du Store est nulle (c'est un serveur de fichiers quoi) ?

- Allons au bout de la projection, et développons le thème de la concurrence déloyale dans un autre domaine.
Imaginons qu'un acteur, Cerberus Industries, à force de travail, d'intelligence et de chance, développe un procédé de culture révolutionnaire de tous les légumes qui divise leur coût de production par trois.
Il prend le monde agricole de vitesse, tue rapidement la concurrence sur quelques années, et devient incontournable sur le marché.
Tant qu'il en reste là, c'est de la compétition commerciale, et dans le sens de l'intérêt général, ça se défend.
Bon, c'est bien la merde pour les agriculteurs, mais mettons qu'ils ont été parfaitement recasés, et qu'on a crevé toutes les roues de leurs tracteurs en même temps, préventivement comme dirait José Garcia.
Fort de sa position, Cerberus quadruple les prix.
Protestations générales, la filiale historique est morte, la concurrence est impossible, et Cerberus de nous dire, dans une douce ironie, "qu'on n'a qu'à manger des pommes".
Sans régulateur, et par ruse, l'intérêt général se retrouve annihilé au profit d'un intérêt particulier.
Une organisation n'a d'intérêt pour ses clients que si elle rend un service dans des conditions équitables.
Si les conditions sont déséquilibrées dans des proportions qui atteignent directement l'intérêt général, quel est l'intérêt pour la collectivité de maintenir l'acteur dans sa position ?
Une entreprise, même privée, même géniale, se doit d'être globalement au service de son environnement, tout comme une cellule dans un organisme, ou a minima de ne pas trop le dégrader.
Dans ce dernier cas, si la cellule devient nocive, l'organisme se défend, et ce n'est pas seulement normal.
C'est vital.
Modifié le 28/02/2024 à 19h40

Historique des modifications :

Posté le 28/02/2024 à 19h38


Jouons !

- L'adaptation au changement est inhérent à toute entreprise, et c'est son quotidien - littéralement.
En permanence, nous devons nous adapter à des contraintes extérieures, et composer avec.
L'aléa peut venir des clients, des fournisseurs, des collaborateurs, de l'état, du propriétaire, des conjonctures économiques, de la banque, des taux directeurs, de l'actionnaire, de l'environnement, du matériel, de nouvelles normes, de la faute à pas de chance...
Avoir une contrainte de plus à gérer dans le contexte d'une boite comme Apple sur cette question de la régulation et des PWAs, bon, arrêtons de tourner autour du pot, c'est complètement mineur et gérable.
Le fond du refus n'est pas technique, et comme je le disais ailleurs, toute leur attitude autour du thème montre bien que le fond est économique et (anti-) concurrentiel.

- Ensuite, nous ne sommes pas un acteur hégémonique sur les telcos - personne ne l'est vraiment d'ailleurs, en mettant Orange de côté dans certains contextes (dont le GCBLO qui a fait parler de lui récemment par exemple).
Nous devons nous adapter ou mourir, car d'autres vont s'adapter et survivre.
Autrement dit, l'environnement au sens large contraint nos actions, et nous devons coller aux circonstances.
Nous avons déjà eu plein de questionnements autour de ces thèmes réseau, et les problèmes que nous rencontrons sont de diverses natures. Peu importe leur origine, notre job est de les régler, ou les gérer à minima.
Dans le cas d'Apple, c'est très différent.
C'est un cas rare où l'acteur a suffisamment de poids pour contraindre lui, à l'envi et à son seul profit l'ensemble des acteurs de sa sphère d'activité, qui est devenue indispensable aujourd'hui, et sans aucun contre-pouvoir. Grâce à sa position acquise de haute lutte et avec une dose certaine de travail, d'intelligence et de chance, Apple tord le bras à tous les acteurs qui se développent dans son sillage, dont les éditeurs d'apps.
C'est la stratégie du "tu vas faire quoi ?".
Apple considère qu'il fournit la plateforme aux devs, et qu'une partie de la valeur de leur travail leur revient, et que s'ils ne sont pas contents, ils n'ont qu'à mourir.
Tout le monde ferme sa gueule du coup, perd ses 20% de marge qui font la différence entre la vie et la survie (coucou Spotify), et il ne s'est rien passé de majeur pendant 10 ans.
Du point de vue d'Apple et des actionnaires, c'est un move rationnel.
Du point de vue général, à quel moment c'est normal de prendre 20% de la valeur de l'ensemble des services du service software portable mondial, quand il n'y a pas de plateforme alternative, que le matériel est déjà chèrement vendu, et que la valeur d'intermédiation de Store est nulle (c'est un serveur de fichiers quoi) ?

- Allons au bout de la projection, et développons le thème de la concurrence déloyale dans un autre domaine.
Imaginons qu'un acteur, Cerberus Industries, à force de travail, d'intelligence et de chance, développe un procédé de culture révolutionnaire de tous les légumes qui divise leur coût de production par trois.
Il prend le monde agricole de vitesse, tue rapidement la concurrence sur quelques années, et devient incontournable sur le marché.
Tant qu'il en reste là, c'est de la compétition commerciale, et dans le sens de l'intérêt général, ça se défend.
Bon, c'est bien la merde pour les agriculteurs, mais mettons qu'ils ont été parfaitement recasés, et qu'on a crevé toutes les roues de leurs tracteurs en même temps, préventivement comme dirait José Garcia.
Fort de leur position, Cerberus quadruple les prix.
Protestations générales, la filiale historique est morte, la concurrence est impossible, et Cerberus de nous dire, dans une douce ironie, "qu'on n'a qu'à manger des pommes".
Sans régulateur, et par ruse, l'intérêt général se retrouve annihilé au profit d'un intérêt particulier.
Une organisation n'a d'intérêt pour ses clients que si elle rend un service dans des conditions équitables.
Si les conditions sont déséquilibrées dans des proportions qui atteignent directement l'intérêt général, quel est l'intérêt pour la collectivité de maintenir l'acteur dans sa position ?
Une entreprise, même privée, même géniale, se doit d'être globalement au service de son environnement, tout comme une cellule dans un organisme, ou a minima de ne pas trop le dégrader.
Dans ce dernier cas, si la cellule devient nocive, l'organisme se défend, et ce n'est pas seulement normal.
C'est vital.

Ferd

Jouons !

- L'adaptation au changement est inhérent à toute entreprise, et c'est son quotidien - littéralement.
En permanence, nous devons nous adapter à des contraintes extérieures, et composer avec.
L'aléa peut venir des clients, des fournisseurs, des collaborateurs, de l'état, du propriétaire, des conjonctures économiques, de la banque, des taux directeurs, de l'actionnaire, de l'environnement, du matériel, de nouvelles normes, de la faute à pas de chance...
Avoir une contrainte de plus à gérer dans le contexte d'une boite comme Apple sur cette question de la régulation et des PWAs, bon, arrêtons de tourner autour du pot, c'est complètement mineur et gérable.
Le fond du refus n'est pas technique, et comme je le disais ailleurs, toute leur attitude autour du thème montre bien que le fond est économique et (anti-) concurrentiel.

- Ensuite, nous ne sommes pas un acteur hégémonique sur les telcos - personne ne l'est vraiment d'ailleurs, en mettant Orange de côté dans certains contextes (dont le GCBLO qui a fait parler de lui récemment par exemple).
Nous devons nous adapter ou mourir, car d'autres vont s'adapter et survivre.
Autrement dit, l'environnement au sens large contraint nos actions, et nous devons coller aux circonstances.
Nous avons déjà eu plein de questionnements autour de ces thèmes réseau, et les problèmes que nous rencontrons sont de diverses natures. Peu importe leur origine, notre job est de les régler, ou les gérer à minima.
Dans le cas d'Apple, c'est très différent.
C'est un cas rare où l'acteur a suffisamment de poids pour contraindre lui, à l'envi et à son seul profit l'ensemble des acteurs de sa sphère d'activité, qui est devenue indispensable aujourd'hui, et sans aucun contre-pouvoir. Grâce à sa position acquise de haute lutte et avec une dose certaine de travail, d'intelligence et de chance, Apple tord le bras à tous les acteurs qui se développent dans son sillage, dont les éditeurs d'apps.
C'est la stratégie du "tu vas faire quoi ?".
Apple considère qu'il fournit la plateforme aux devs, et qu'une partie de la valeur de leur travail leur revient, et que s'ils ne sont pas contents, ils n'ont qu'à mourir.
Tout le monde ferme sa gueule du coup, perd ses 20% de marge qui font la différence entre la vie et la survie (coucou Spotify), et il ne s'est rien passé de majeur pendant 10 ans.
Du point de vue d'Apple et des actionnaires, c'est un move rationnel.
Du point de vue général, à quel moment c'est normal de prendre 20% de la valeur de l'ensemble des services du service software portable mondial, quand il n'y a pas de plateforme alternative, que le matériel est déjà chèrement vendu, et que la valeur d'intermédiation du Store est nulle (c'est un serveur de fichiers quoi) ?

- Allons au bout de la projection, et développons le thème de la concurrence déloyale dans un autre domaine.
Imaginons qu'un acteur, Cerberus Industries, à force de travail, d'intelligence et de chance, développe un procédé de culture révolutionnaire de tous les légumes qui divise leur coût de production par trois.
Il prend le monde agricole de vitesse, tue rapidement la concurrence sur quelques années, et devient incontournable sur le marché.
Tant qu'il en reste là, c'est de la compétition commerciale, et dans le sens de l'intérêt général, ça se défend.
Bon, c'est bien la merde pour les agriculteurs, mais mettons qu'ils ont été parfaitement recasés, et qu'on a crevé toutes les roues de leurs tracteurs en même temps, préventivement comme dirait José Garcia.
Fort de sa position, Cerberus quadruple les prix.
Protestations générales, la filiale historique est morte, la concurrence est impossible, et Cerberus de nous dire, dans une douce ironie, "qu'on n'a qu'à manger des pommes".
Sans régulateur, et par ruse, l'intérêt général se retrouve annihilé au profit d'un intérêt particulier.
Une organisation n'a d'intérêt pour ses clients que si elle rend un service dans des conditions équitables.
Si les conditions sont déséquilibrées dans des proportions qui atteignent directement l'intérêt général, quel est l'intérêt pour la collectivité de maintenir l'acteur dans sa position ?
Une entreprise, même privée, même géniale, se doit d'être globalement au service de son environnement, tout comme une cellule dans un organisme, ou a minima de ne pas trop le dégrader.
Dans ce dernier cas, si la cellule devient nocive, l'organisme se défend, et ce n'est pas seulement normal.
C'est vital.
Jouons !


Un petit Quake III Arena ça me détendrait bien. Je suis partant :)

(désolé pour l'apparté)

J'avoue ne pas trop comprendre ton message. D'un côté, tu précises ne pas être un expert (d'un point de vue technique dans le dev j'entends), mais là, tu affirmes sans autre considération que le choix d'Apple est purement commercial et non technique, et enchaine sur des considérations purement commerciales. Du coup, je m'interroge.

Je ne cherche pas à défendre Apple (comme déjà dit, je ne suis pas trop fan de leur politique). Mais le dev étant mon domaine de compétence depuis de nombreuses années, les arguments "techniques" qu'ils avancent sont tout à fait plausibles.

Ce qui parait simple (d'un point de vue utilisateur) peut parfois être compliqué (d'un point de vue technique) et inversement.

fdorin

Jouons !


Un petit Quake III Arena ça me détendrait bien. Je suis partant :)

(désolé pour l'apparté)

J'avoue ne pas trop comprendre ton message. D'un côté, tu précises ne pas être un expert (d'un point de vue technique dans le dev j'entends), mais là, tu affirmes sans autre considération que le choix d'Apple est purement commercial et non technique, et enchaine sur des considérations purement commerciales. Du coup, je m'interroge.

Je ne cherche pas à défendre Apple (comme déjà dit, je ne suis pas trop fan de leur politique). Mais le dev étant mon domaine de compétence depuis de nombreuses années, les arguments "techniques" qu'ils avancent sont tout à fait plausibles.

Ce qui parait simple (d'un point de vue utilisateur) peut parfois être compliqué (d'un point de vue technique) et inversement.
Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.

Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.

Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.

Pour deux raisons.

La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.

La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu web), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.

Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.

My 50 cents.
Modifié le 28/02/2024 à 22h35

Historique des modifications :

Posté le 28/02/2024 à 22h23


Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.

Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.

Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.

Pour deux raisons.

La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.

La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument massivement dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.

Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.

My 50 cents.

Posté le 28/02/2024 à 22h34


Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.

Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.

Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.

Pour deux raisons.

La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.

La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.

Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.

My 50 cents.

Ferd

Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.

Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.

Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.

Pour deux raisons.

La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.

La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu web), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.

Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.

My 50 cents.
Je suis plutôt d'accord dans l'ensemble avec ce que tu dis.

Simplement, concernant les PWA, j'avoue que je reste plutôt sceptique sur l'argument purement marketing. Tu rappelles, et à juste titre, toutes les manœuvres réalisées pour décourager les stores alternatifs, les moteurs de rendu pour les navigateurs et autres joyeuseries liées au DMA.

Cela me semble tellement dérisoire de rajouter une petite touche sur les PWA à la vue de toutes les autres énormités qu'ils ont mis en place. Cela me semble vraiment ridicule. Bien sûr, je peux tout à fait me tromper. Mais pour le coup, l'argument technique me parait beaucoup plus plausible que l'argument marketing (bien que l'un n'empêche pas l'autre, je l'admet).

L'argument sécuritaire d'Apple, c'est qu'en l'état, il n'est pas possible de garantir une isolation de chaque PWA. A priori, aujourd'hui c'est fait par le moteur même. Changer de moteur implique donc que la séparation ne soit plus garantie. Autrement dit, en changeant de moteur de rendu (et toujours en l'état actuel des choses) les applications auront accès aux données des autres applications. Ce qui n'est pas forcément souhaitable.

Est-ce qu'Apple à les reins suffisamment solides pour faire les modifications, je pense pouvoir affirmer sans trop me tromper que oui. Maintenant, est-ce qu'elle a l'obligation de le faire ? Non. Est-ce que légalement, on peut l'obliger à le faire ? Je ne suis pas certains non plus. On peut l'obliger à respecter un cadre réglementaire (comme le DMA), mais il ne me semble pas possible de lui dire comment le faire (si un juriste passe par là pour confirmer). Si pour respecter le DMA, Apple souhaite retirer une fonctionnalité, cela me parait difficile de l'y contraindre, à moins que le support des PWA soit inclus directement dans le DMA (ce dont je doute fortement).

Par contre, une fonctionnalité prévue par contrat qui serait retirée (par ex. désactivation complète du NFC), là, je pense qu'il serait possible d'agir. Mais ce serait par "rupture de contrat" et non pas dans le cadre d'un nouveau cadre. Et ce serait à chaque utilisateur d'agir, pas à l'Europe.

fdorin

Je suis plutôt d'accord dans l'ensemble avec ce que tu dis.

Simplement, concernant les PWA, j'avoue que je reste plutôt sceptique sur l'argument purement marketing. Tu rappelles, et à juste titre, toutes les manœuvres réalisées pour décourager les stores alternatifs, les moteurs de rendu pour les navigateurs et autres joyeuseries liées au DMA.

Cela me semble tellement dérisoire de rajouter une petite touche sur les PWA à la vue de toutes les autres énormités qu'ils ont mis en place. Cela me semble vraiment ridicule. Bien sûr, je peux tout à fait me tromper. Mais pour le coup, l'argument technique me parait beaucoup plus plausible que l'argument marketing (bien que l'un n'empêche pas l'autre, je l'admet).

L'argument sécuritaire d'Apple, c'est qu'en l'état, il n'est pas possible de garantir une isolation de chaque PWA. A priori, aujourd'hui c'est fait par le moteur même. Changer de moteur implique donc que la séparation ne soit plus garantie. Autrement dit, en changeant de moteur de rendu (et toujours en l'état actuel des choses) les applications auront accès aux données des autres applications. Ce qui n'est pas forcément souhaitable.

Est-ce qu'Apple à les reins suffisamment solides pour faire les modifications, je pense pouvoir affirmer sans trop me tromper que oui. Maintenant, est-ce qu'elle a l'obligation de le faire ? Non. Est-ce que légalement, on peut l'obliger à le faire ? Je ne suis pas certains non plus. On peut l'obliger à respecter un cadre réglementaire (comme le DMA), mais il ne me semble pas possible de lui dire comment le faire (si un juriste passe par là pour confirmer). Si pour respecter le DMA, Apple souhaite retirer une fonctionnalité, cela me parait difficile de l'y contraindre, à moins que le support des PWA soit inclus directement dans le DMA (ce dont je doute fortement).

Par contre, une fonctionnalité prévue par contrat qui serait retirée (par ex. désactivation complète du NFC), là, je pense qu'il serait possible d'agir. Mais ce serait par "rupture de contrat" et non pas dans le cadre d'un nouveau cadre. Et ce serait à chaque utilisateur d'agir, pas à l'Europe.
On va avoir du mal à trancher formellement sur les PWA, mais :

En appliquant le principe du rasoir d'Ockham, et sachant qu'Apple a déjà été mesquin à de multiples reprises par le passé (les exemples sont nombreux, qu'on parle de chiffonnette, de propriété intellectuelle sur le symbole de la pomme, de la politique de validation des apps, du ghosting des journaux Mac un peu trop indépendants, de tout ce qui s'approche de près ou de loin à leurs intérêts.....), sachant le contexte de cette décision, toute leur attitude depuis toujours autour du sujet de l'ouverture d'iOS, et sachant aussi qu'ils ont des ressources devs conséquentes, moi je mise tout sur l'enfumage.
C'est pas vindicatif, c'est juste de la logique.

Ferd

On va avoir du mal à trancher formellement sur les PWA, mais :

En appliquant le principe du rasoir d'Ockham, et sachant qu'Apple a déjà été mesquin à de multiples reprises par le passé (les exemples sont nombreux, qu'on parle de chiffonnette, de propriété intellectuelle sur le symbole de la pomme, de la politique de validation des apps, du ghosting des journaux Mac un peu trop indépendants, de tout ce qui s'approche de près ou de loin à leurs intérêts.....), sachant le contexte de cette décision, toute leur attitude depuis toujours autour du sujet de l'ouverture d'iOS, et sachant aussi qu'ils ont des ressources devs conséquentes, moi je mise tout sur l'enfumage.
C'est pas vindicatif, c'est juste de la logique.
Chacun sa logique ;)

Avec le rasoir d'Ockahm (dont je suis un fervent utilisateur ^^) j'arrive à la conclusion que ce n'est pas pour des raisons marketing, mais technique : PWA est peu utilisée, PWA ne rapporte rien (pas de commission), le support de moteur de rendu aurait un coût de dev plus ou moins conséquent, c'est loin d'être indispensable => poubelle.

C'est peut-être aussi ma vision de chef d'entreprise qui veut ça. Et comme je le disais dans un autre commentaire, les deux visions ne sont pas forcément contradictoire. Il peut s'agir des deux !

Après, pour le reste, je suis entièrement d'accord avec toi (sauf que moi je n'ai pas d'iPhone :p). Apple sait faire preuve de beaucoup d'imagination pour mettre des bâtons dans les roues. Elle nous l'a montré à mainte reprises par le passé. Mais là, c'est tellement "easy" comme méthode (pour l'abandon du PWA hein) que je me dis que cela ne leur ressemble pas ! Il nous ont habitué à "mieux" (le mieux est ironique hein !!!)

fdorin

Chacun sa logique ;)

Avec le rasoir d'Ockahm (dont je suis un fervent utilisateur ^^) j'arrive à la conclusion que ce n'est pas pour des raisons marketing, mais technique : PWA est peu utilisée, PWA ne rapporte rien (pas de commission), le support de moteur de rendu aurait un coût de dev plus ou moins conséquent, c'est loin d'être indispensable => poubelle.

C'est peut-être aussi ma vision de chef d'entreprise qui veut ça. Et comme je le disais dans un autre commentaire, les deux visions ne sont pas forcément contradictoire. Il peut s'agir des deux !

Après, pour le reste, je suis entièrement d'accord avec toi (sauf que moi je n'ai pas d'iPhone :p). Apple sait faire preuve de beaucoup d'imagination pour mettre des bâtons dans les roues. Elle nous l'a montré à mainte reprises par le passé. Mais là, c'est tellement "easy" comme méthode (pour l'abandon du PWA hein) que je me dis que cela ne leur ressemble pas ! Il nous ont habitué à "mieux" (le mieux est ironique hein !!!)
Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜

L’avenir nous éclairera peut être un jour sur cette décision d’Apple.

Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).
Je trouve ça mesquin enough, moi !

Ferd

Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜

L’avenir nous éclairera peut être un jour sur cette décision d’Apple.

Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).
Je trouve ça mesquin enough, moi !
Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜


Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre :smack:
Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).


Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API

PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.

[edit]
Après, niveau API, il faut faire attention au support par les navigateurs. Certains sont très en avance (Chrome) par rapport à d'autres (Safari).
Modifié le 29/02/2024 à 18h36

Historique des modifications :

Posté le 29/02/2024 à 18h34


Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜


Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre :smack:
Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).


Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API

PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.

fdorin

Personne n’est parfait, ne pas avoir d’iPhone ne fait pas forcément de toi une mauvaise personne 😜


Tel est pris qui croyait prendre. Bien joué. Et c'est de bonne guerre :smack:
Tiens, d’ailleurs, pierre de plus dans mon jardin, en serrant la vis sur les pwas, ils ferment la dernière possibilité de ne pas passer par leur store (les stores alternatifs étants en pratique insoutenables avec leurs nouvelles propositions).


Je n'avais pas vu ça sous cet angle. Je l'avoue. En même temps, je n'ai pas une formidable expérience avec les PWAs. J'ai des comportements "agaçants" :
- tu le lances, il freeze, obliger de le fermer complètement et de le rouvrir
- parfois, quand je le lance, il se ferme direct. Obligé de le rouvrir
- sans compter les limitations d'API

PS : après vérification, les limitations sont moins vrai aujourd'hui qu'à une époque pas si lointaine. De nombreuses API sont maintenant disponibles. Donc à moins d'avoir besoin des contacts, des SMS, du NFC, de faire des Widgets ou autre truc un peu plus poussé d'un point de vue intégration avec le téléphone, c'est a priori utilisable.

[edit]
Après, niveau API, il faut faire attention au support par les navigateurs. Certains sont très en avance (Chrome) par rapport à d'autres (Safari).
https://www.igen.fr/ios/2024/03/surprise-ios-174-va-finalement-maintenir-les-pwa-en-europe-142251

Tiens donc.

Ferd

https://www.igen.fr/ios/2024/03/surprise-ios-174-va-finalement-maintenir-les-pwa-en-europe-142251

Tiens donc.
On y lit :
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.

Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.

Édit : correction du lien
Modifié le 01/03/2024 à 18h59

Historique des modifications :

Posté le 01/03/2024 à 17h41


On y lit :
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.

Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.

fred42

On y lit :
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.

Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.

Édit : correction du lien
Une seconde, je sors ma boucle de cristal.
Je vois...
Je vois....

Je vois qu'ils sont plus exposés sur l'ouverture des apps en général que sur les moteurs de rendu web en particulier dans cette affaire.

Ils ont dû tenter le truc discret pour avoir une petite compensation mesquine à l'ouverture potentielle du Store à d'autres acteurs, qu'ils savent inévitable, et pas forcément selon leurs termes.
C'était le moment d'avoir une approche ferme, quitte à ouvrir leur position au fil des négos.
Vu que ça commençait à se voir cette histoire des PWAs, leurs avocats ont dû leur dire de ne pas risquer de voir cette limitation se retourner contre eux.
C'est somme toute assez mineur pour eux, comparativement au reste du dossier.

My 50 euros (vous n'iriez pas voir un voyant à 50 cents, ne faites pas cette tête).

Ferd

Une seconde, je sors ma boucle de cristal.
Je vois...
Je vois....

Je vois qu'ils sont plus exposés sur l'ouverture des apps en général que sur les moteurs de rendu web en particulier dans cette affaire.

Ils ont dû tenter le truc discret pour avoir une petite compensation mesquine à l'ouverture potentielle du Store à d'autres acteurs, qu'ils savent inévitable, et pas forcément selon leurs termes.
C'était le moment d'avoir une approche ferme, quitte à ouvrir leur position au fil des négos.
Vu que ça commençait à se voir cette histoire des PWAs, leurs avocats ont dû leur dire de ne pas risquer de voir cette limitation se retourner contre eux.
C'est somme toute assez mineur pour eux, comparativement au reste du dossier.

My 50 euros (vous n'iriez pas voir un voyant à 50 cents, ne faites pas cette tête).
Tu prends ça comme une négo, ton côté entrepreneur peut-être.

Mais ce n'est pas une négo, c'est plus proche d'un procès. La Commission a ici un pouvoir de sanction et la crédibilité des DSA et DMA en dépend et je n'ai pas l'impression que Thierry Breton soit prêt à la négociation.
Les contrôleurs d'accès (pour le DMA) et les plateformes (pour le DSA) n'ont pas intérêt à jouer au plus fin.
Ils pourront faire traîner et contester auprès de la CJUE, mais ils risquent bien de perdre au final.

fred42

On y lit :
À cette fin, les web apps ajoutées à l’écran d’accueil reposeront toujours sur WebKit et uniquement sur lui.

Voilà pourquoi ils ont changé d'avis sans que ça leur coûte. Ils font comme avant avec leur moteur de rendu web.
Cela me semble non conforme au DMA. Le 7 de l'article 5 du DMA que j'avais cité ici interdisant d'imposer un navigateur internet.

Édit : correction du lien
Cela me semble être une zone grise.

Le DMA mentionné explicitement l'usage d'un moteur de rendu au sein d'un navigateur internet, car cela viendrait influer grandement impacter les possibilités et les performances des navigateurs.

Une PWA n'est pas un navigateur. C'est une application. Elle repose sur un moteur de rendu pour son fonctionnement, mais cela reste une application et l'éditeur n'est pas contraint à ce choix. Il peut utiliser des alternatives, notamment en développant une application native.

En bref, c'est un beau casse tête, juridiquement parlant.

fdorin

Cela me semble être une zone grise.

Le DMA mentionné explicitement l'usage d'un moteur de rendu au sein d'un navigateur internet, car cela viendrait influer grandement impacter les possibilités et les performances des navigateurs.

Une PWA n'est pas un navigateur. C'est une application. Elle repose sur un moteur de rendu pour son fonctionnement, mais cela reste une application et l'éditeur n'est pas contraint à ce choix. Il peut utiliser des alternatives, notamment en développant une application native.

En bref, c'est un beau casse tête, juridiquement parlant.
Mon lien dans mon commentaire précédent était pourri (je l'ai corrigé) mais je recopie ici la partie d'article du DMA que je citais en barrant ce qui n'a pas trait aux navigateurs :
Le contrôleur d’accès n’exige pas des utilisateurs finaux qu’ils utilisent, ni des entreprises utilisatrices qu’elles utilisent, proposent ou interagissent avec un service d’identification, un navigateur internet ou un service de paiement, ou un service technique qui appuie la fourniture des services de paiement, tels que des systèmes de paiement destinés aux achats dans des applications, de ce contrôleur d’accès dans le cadre des services fournis par les entreprises utilisatrices en ayant recours aux services de plateforme essentiels de ce contrôleur d’accès.


Une PWA s'appuie sur un navigateur (et pas le seul moteur de rendu) si j'en crois l'article en anglais de Wikipédia.

Et ici, Apple impose à la fois aux utilisateurs et aux entreprises utilisatrices d'utiliser son navigateur WEB pour les PWA.
Je ne vois pas comment cela peut être conforme au DMA.

Si une entreprise choisit de faire une PWA et pas une application native ni une application en techno web qui embarque son propre moteur de rendu, Apple ne doit pas lui imposer Safari/Webkit.

fred42

Mon lien dans mon commentaire précédent était pourri (je l'ai corrigé) mais je recopie ici la partie d'article du DMA que je citais en barrant ce qui n'a pas trait aux navigateurs :
Le contrôleur d’accès n’exige pas des utilisateurs finaux qu’ils utilisent, ni des entreprises utilisatrices qu’elles utilisent, proposent ou interagissent avec un service d’identification, un navigateur internet ou un service de paiement, ou un service technique qui appuie la fourniture des services de paiement, tels que des systèmes de paiement destinés aux achats dans des applications, de ce contrôleur d’accès dans le cadre des services fournis par les entreprises utilisatrices en ayant recours aux services de plateforme essentiels de ce contrôleur d’accès.


Une PWA s'appuie sur un navigateur (et pas le seul moteur de rendu) si j'en crois l'article en anglais de Wikipédia.

Et ici, Apple impose à la fois aux utilisateurs et aux entreprises utilisatrices d'utiliser son navigateur WEB pour les PWA.
Je ne vois pas comment cela peut être conforme au DMA.

Si une entreprise choisit de faire une PWA et pas une application native ni une application en techno web qui embarque son propre moteur de rendu, Apple ne doit pas lui imposer Safari/Webkit.
Une PWA est une application. Elle ne nécessite pas un navigateur, mais des technologies associées classiquement à un navigateur (HTML, javascript, CSS).

Une application n'est pas nécessairement un PWA. Le développeur à le choix, et dans ce sens, Apple n'impose pas de moteur de rendu (ou de navigateur) pour le développement d'une application.

L'utilisateur a le choix aussi. Il peut utiliser ou pas l'application. Ou utiliser une alternative.

Dans le cas du navigateur, l'utilisateur se retrouvait, avant le DMA, à utiliser quoi qu'il arrive Webkit.

Pour résumer :
- le développeur n'est pas contraint à utiliser Webkit
- l'utilisateur n'est pas contraint par le choix du contrôleur d'accès (ici Apple), mais par le choix des développeurs.

Apple n'exige pas/plus des utilisateurs d'application d'utiliser Webkit.
Apple n'exige pas/plus des éditeurs qu'ils utilisent Webkit pour développer une application.
Les développeurs sont libres de faire du PWA ou du natif.
Dans le cas d'une application PWA, alors Webkit sera utilisé.

On peut trouver ça limite (et je trouve que cela l'est), mais juridiquement parlant, je ne pense pas qu'on puisse qualifier cela d'exigence dans la mesure où des alternatives existes. Et si ce n'est pas une exigence, ce n'est pas contraire au DMA.

Après, ce n'est que mon interprétation. Attendons de voir l'analyse que fera la commission européenne à ce sujet. C'est son analyse qui fera foi, pas nos avis respectifs !

fdorin

Une PWA est une application. Elle ne nécessite pas un navigateur, mais des technologies associées classiquement à un navigateur (HTML, javascript, CSS).

Une application n'est pas nécessairement un PWA. Le développeur à le choix, et dans ce sens, Apple n'impose pas de moteur de rendu (ou de navigateur) pour le développement d'une application.

L'utilisateur a le choix aussi. Il peut utiliser ou pas l'application. Ou utiliser une alternative.

Dans le cas du navigateur, l'utilisateur se retrouvait, avant le DMA, à utiliser quoi qu'il arrive Webkit.

Pour résumer :
- le développeur n'est pas contraint à utiliser Webkit
- l'utilisateur n'est pas contraint par le choix du contrôleur d'accès (ici Apple), mais par le choix des développeurs.

Apple n'exige pas/plus des utilisateurs d'application d'utiliser Webkit.
Apple n'exige pas/plus des éditeurs qu'ils utilisent Webkit pour développer une application.
Les développeurs sont libres de faire du PWA ou du natif.
Dans le cas d'une application PWA, alors Webkit sera utilisé.

On peut trouver ça limite (et je trouve que cela l'est), mais juridiquement parlant, je ne pense pas qu'on puisse qualifier cela d'exigence dans la mesure où des alternatives existes. Et si ce n'est pas une exigence, ce n'est pas contraire au DMA.

Après, ce n'est que mon interprétation. Attendons de voir l'analyse que fera la commission européenne à ce sujet. C'est son analyse qui fera foi, pas nos avis respectifs !
Dans ce cas, continuons avec le même type d'arguments.
Avant le DMA, on pouvait dire ; les développeurs ont le choix de ne pas développer des application natives sur iOS et de ne pas utiliser le store d'Apple ; c'est le choix des développeurs de développer sur iOS qui les obligent à utiliser le store d'Apple.

Mais l'UE a décidé que ce genre d'arguments (que certains ici défend(ai)ent) n'étaient pas acceptable.
Elle a donc décidé qu'il fallait obliger les contrôleurs d'accès à autoriser les stores alternatifs, les services de paiement alternatifs, l'accès au NFC pour les paiements et les navigateurs alternatifs.

Là, Apple, dans un cas particulier ne donne pas le choix du navigateur ni au développeur ni à l'utilisateur.
C'est d'autant plus dommageable que les PWA sur Safari étaient ou sont toujours moins complètes que sur Chrome (par exemple).

fred42

Dans ce cas, continuons avec le même type d'arguments.
Avant le DMA, on pouvait dire ; les développeurs ont le choix de ne pas développer des application natives sur iOS et de ne pas utiliser le store d'Apple ; c'est le choix des développeurs de développer sur iOS qui les obligent à utiliser le store d'Apple.

Mais l'UE a décidé que ce genre d'arguments (que certains ici défend(ai)ent) n'étaient pas acceptable.
Elle a donc décidé qu'il fallait obliger les contrôleurs d'accès à autoriser les stores alternatifs, les services de paiement alternatifs, l'accès au NFC pour les paiements et les navigateurs alternatifs.

Là, Apple, dans un cas particulier ne donne pas le choix du navigateur ni au développeur ni à l'utilisateur.
C'est d'autant plus dommageable que les PWA sur Safari étaient ou sont toujours moins complètes que sur Chrome (par exemple).
La grosse différence entre un PWA et une application native, c'est que le PWA ne permet pas un accès complet au téléphone. Tu ne peux pas accéder aux Contacts, aux SMS, aux appels, etc. Les PWA ne sont pas disponibles sur le store non plus (bien qu'en théorie, ils pourraient l'être).

Une PWA ne peut pas faire tout ce que fais une application native, une application native peut faire tout ce que fait une PWA, sans compter qu'Apple à un droit de vie ou de mort d'une application sur l'Apple Store. Pour un certain nombre d'applications, l'application native était la seule solution. Notons également que les PWA sont disponibles depuis 2018 seulement (et avec encore moins de droit à l'époque par rapport à aujourd'hui) par rapport aux applications natives qui ont débarqués en 2008 (10 ans d'écart).

Là où je veux en venir, c'est que mon interprétation ou la tienne du "jargon juridique" (sans aucun sens péjoratif ici) n'a pas de valeur. Seule compte celle des autorités (ici l'Europe).

On peut prendre l'exemple des paywall pour les cookies, où, pour beaucoup, cela enfreint le caractère libre du consentement (qui est, pour rappel, un des 4 critères pour que le consentement soit valide). Pourtant, cela a été validé, dans une certaine mesure, par les CNILs.

L'extrait que tu cites du DMA est très intéressant, mais sa compréhension dépend de l'interprétation de certains termes, interprétation d'un point de vue juridique, pas d'un point de vue technique, notamment sur la notion de "navigateur internet" (et pour savoir si on considère qu'une PWA utilise un navigateur ou un moteur de rendu) et sur la notion "d'exigence" en présence d'alternative.

Que les choses soient claires. Je ne cherche pas à dire que tu as tord et moi raison sur le fait que cela enfreigne potentiellement le DMA (on s'en fout, et ce sont les autorités qui trancheront à ce sujet). Je cherchais juste à montrer que la conformité au DMA dépend de l'interprétation juridique que l'on fait des termes, afin de répondre à ton interrogation de savoir comment cela pourrait être conforme au DMA ;)

fdorin

La grosse différence entre un PWA et une application native, c'est que le PWA ne permet pas un accès complet au téléphone. Tu ne peux pas accéder aux Contacts, aux SMS, aux appels, etc. Les PWA ne sont pas disponibles sur le store non plus (bien qu'en théorie, ils pourraient l'être).

Une PWA ne peut pas faire tout ce que fais une application native, une application native peut faire tout ce que fait une PWA, sans compter qu'Apple à un droit de vie ou de mort d'une application sur l'Apple Store. Pour un certain nombre d'applications, l'application native était la seule solution. Notons également que les PWA sont disponibles depuis 2018 seulement (et avec encore moins de droit à l'époque par rapport à aujourd'hui) par rapport aux applications natives qui ont débarqués en 2008 (10 ans d'écart).

Là où je veux en venir, c'est que mon interprétation ou la tienne du "jargon juridique" (sans aucun sens péjoratif ici) n'a pas de valeur. Seule compte celle des autorités (ici l'Europe).

On peut prendre l'exemple des paywall pour les cookies, où, pour beaucoup, cela enfreint le caractère libre du consentement (qui est, pour rappel, un des 4 critères pour que le consentement soit valide). Pourtant, cela a été validé, dans une certaine mesure, par les CNILs.

L'extrait que tu cites du DMA est très intéressant, mais sa compréhension dépend de l'interprétation de certains termes, interprétation d'un point de vue juridique, pas d'un point de vue technique, notamment sur la notion de "navigateur internet" (et pour savoir si on considère qu'une PWA utilise un navigateur ou un moteur de rendu) et sur la notion "d'exigence" en présence d'alternative.

Que les choses soient claires. Je ne cherche pas à dire que tu as tord et moi raison sur le fait que cela enfreigne potentiellement le DMA (on s'en fout, et ce sont les autorités qui trancheront à ce sujet). Je cherchais juste à montrer que la conformité au DMA dépend de l'interprétation juridique que l'on fait des termes, afin de répondre à ton interrogation de savoir comment cela pourrait être conforme au DMA ;)
Dit comme ça, on est d'accord. Mais on ne commenterait pas grand chose s'il fallait attendre les décisions définitives des juridictions ! :D

Et pour les paywall de coockies, on verra ce qui va sortir de l'affaire Méta et ses abonnements payants.
Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?
La seule chose que j'ai en tête à ce sujet, mais c'est peut-être que j'en ai raté ou oublié, c'est la décision de notre Conseil d'État qui a dit à la CNIL qu'elle ne pouvait pas dire dans ses recommandations (soft law) que les coockies walls étaient interdits parce que ça dépendait entre autre des offres des concurrents. Par exemple, Marmiton pouvait mettre un cookie wall si les recettes restaient accessibles sur d'autres sites.
Et la CNIL française a donc modifié son discours général sur ce sujet puisque la décision du Conseil d'État s'imposait à elle. Cela n'empêchera pas forcément de prendre des décisions contre les cookies wall dans des affaires précises.

fred42

Dit comme ça, on est d'accord. Mais on ne commenterait pas grand chose s'il fallait attendre les décisions définitives des juridictions ! :D

Et pour les paywall de coockies, on verra ce qui va sortir de l'affaire Méta et ses abonnements payants.
Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?
La seule chose que j'ai en tête à ce sujet, mais c'est peut-être que j'en ai raté ou oublié, c'est la décision de notre Conseil d'État qui a dit à la CNIL qu'elle ne pouvait pas dire dans ses recommandations (soft law) que les coockies walls étaient interdits parce que ça dépendait entre autre des offres des concurrents. Par exemple, Marmiton pouvait mettre un cookie wall si les recettes restaient accessibles sur d'autres sites.
Et la CNIL française a donc modifié son discours général sur ce sujet puisque la décision du Conseil d'État s'imposait à elle. Cela n'empêchera pas forcément de prendre des décisions contre les cookies wall dans des affaires précises.
Dit comme ça, on est d'accord. Mais on ne commenterait pas grand chose s'il fallait attendre les décisions définitives des juridictions ! :D


Et puis, pourquoi qu'on gueule sinon :francais:
Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?


De ce que j'ai retenu, le conseil d'état a surtout rappelé à la CNIL qu'elle ne pouvait pas interdire quelque chose par principe, car cela sortait de ses attributions.

La CNIL a ensuite revu un peu sa copie, et donner des consignes / critères d'évaluation pour déterminer la "conformité" des cookie-walls. On peut retrouver tout cela sur sa page dédiée au cookie-walls, notamment avec la notion de "tarif raisonnable", tout en rappelant que le paywall n'est pas "interdit par principe".

Pour finir, l'affaire Meta ne concernera au final que... Meta. La CNIL rappelle en effet que la détermination d'un tarif raisonnable dépend d'une analyse au cas par cas ;)

fdorin

Dit comme ça, on est d'accord. Mais on ne commenterait pas grand chose s'il fallait attendre les décisions définitives des juridictions ! :D


Et puis, pourquoi qu'on gueule sinon :francais:
Tu dis que les CNILs les ont validé dans une certaine mesure, tu as des exemples ?


De ce que j'ai retenu, le conseil d'état a surtout rappelé à la CNIL qu'elle ne pouvait pas interdire quelque chose par principe, car cela sortait de ses attributions.

La CNIL a ensuite revu un peu sa copie, et donner des consignes / critères d'évaluation pour déterminer la "conformité" des cookie-walls. On peut retrouver tout cela sur sa page dédiée au cookie-walls, notamment avec la notion de "tarif raisonnable", tout en rappelant que le paywall n'est pas "interdit par principe".

Pour finir, l'affaire Meta ne concernera au final que... Meta. La CNIL rappelle en effet que la détermination d'un tarif raisonnable dépend d'une analyse au cas par cas ;)

OK, je n'ai donc rien raté à ce sujet.

Ferd

Désolé, j'ai pris ta tentative de parler des telcos comme une forme d'ouverture générale du sujet, et je m'en suis peut-être trop éloigné du coup.

Je ne doute pas que le dev pour permettre à un autre moteur de rendu web de fonctionner sous iOS soit du travail, certainement très conséquent dans l'absolu.
J'ai plus de doutes sur le sujet web apps, qui semble être une vue dans un autre contexte du travail initial qu'une réelle restructuration du code, mais c'est là un uneducated guess, tu as raison.
Un des problèmes de cette affaire est là d'ailleurs, pas grand monde crédible et libre de s'exprimer sur le sujet ne sait vraiment, sauf la communication officielle d'Apple, qui est tout sauf impartiale sur le sujet.

Ce que je soutiens rapidement dans mon message, c'est qu'à l'échelle d'Apple, je suis convaincu que c'est une évolution technique soutenable, et qu'Apple est de mauvaise foi.

Pour deux raisons.

La première, c'est qu'Apple a fait d'iOS sa vache à lait depuis 10 ans, je ne doute pas qu'ils soient très habiles à le faire évoluer. Et ils en ont largement les moyens financiers.
Que les gars parlent de mettre de l'IA locale à toutes les sauces dans iOS 18 d'un côté et ne soient pas capables de faire évoluer leur plateforme de façon "sécurisée" pour une vue d'un moteur de rendu web qui aurait droit de cité sur le système dans l'absolu me fait un peu tiquer.

La seconde est inhérente à la position d'Apple sur le sujet.
Je suis allé parcourir la page d'explication d'Apple que Fred42 a communiqué plus haut
https://developer.apple.com/support/dma-and-apps-in-the-eu#ios-app-eu
Apple ne parle QUE de sécurité pour justifier l'impossible adaptation des Home Screens Apps - et sans que personne ne puisse vérifier d'ailleurs.
J'ai beaucoup de mal avec cet argument, il est employé ad nauseam par Apple pour empêcher l'ouverture de la plateforme à d'autres sources que l'App Store depuis des années, App Store dont le processus de validation officiel est très loin d'être sécurisé lui-même.
Nous avons des ordinateurs depuis des décennies qui tournent sur des systèmes très comparables, et je n'entends pas grand monde se plaindre du fait que Mac OS ne serait pas assez sécurisé.
La sécurité est un argument trop souvent dévoyé pour faire passer toutes sortes de salades à bien des occasions.
Pour souligner l'hypothèse d'une nécessité de protéger leur position, il ne faut pas oublier non plus qu'Apple fait également la chasse aux jailbreaks, aux tentatives de rétro engineering d'iMessage, et à toute tentative d'utiliser librement leur matériel légalement acheté, alors que ce n'est pas une menace pour la sécurité du parc installé qui resterait massivement en version Vanilla.
On peut aussi parler des conditions pour l'apparition des Store alternatifs, où les problèmes ne sont pas techniques apparemment (et on pourrait penser que c'est autrement plus compliqué qu'intégrer un moteur de rendu web), mais bien commerciaux avec des conditions financières complètement délirantes et visiblement injustifiées.

Je veux bien avoir un doute raisonnable, et je ne suis pas fermé à étudier de nouvelles informations inédites et documentées sur le sujet des PWAs, mais mon intuition me hurle que dans cette affaire, qu'Apple nous balade menu.
Une nouvelle fois.

My 50 cents.
100% d'accord avec tes deux derniers messages. Apple est un gamin capricieux a qui on dit qu'il a suffisamment tiré sur la corde.

A l'époque Jobs, Apple était une boite d'enflure, mais qui essayait de garder un semblant de bon copain en dosant ce qui rentre et ce qui sort pour que les gens soient content tout en s'en mettant plein les poches. C'est "fair".

Maintenant à l'époque Cooks, c'est fini, c'est juste devenu une boite de raclure. Le premier prix est à 1000€, l'OS est toujours aussi fermé, Apple garde le contrôle sur absolument tout, dès que tu veux sortir de l'écosystème apple, c'est la merde: filtre photo et angle de rotation en metadata spécifique apple, pas d'accès en mode fichier à travers l'usb, ou alors juste les photos dans des dossiers nommé n'importe comment, toujours pas possible en 2024 de mettre un simple icône en bas de l'écran, l'arrivé enfin de l'usb-c après des années à se gaver sur les royalties lightning, et maintenant la fin des PWA...

D'ailleurs, comment ils savent que les PWA ne sont pas utilisées? Je croyais que le respect de la vie privée était leur priorité.

Plus globalement, Apple et Google ne payent pas (ou très peu) d’impôt et n'apportent donc aucune richesse à la France/Europe. On s'adapte et joue a peu prêt avec les même arguments que Apple envers Spotify. Si Apple n'est pas content, ils ont cas arrêter de vendre en Europe. Ca nous poussera à être créatif.

A titre plus perso, j'ai toujours alterné entre iOS et Android depuis que ca existe, mais je pense que c'est fini pour moi. Android a su s'améliorer en prenant ce qu'il y avait de bon dans iOS (principalement: gestion fine des permissions, patch de sécu de l'OS sur au moins 5 ans). Alors qu'iOS n'a fait que verrouiller de plus en plus. Android n'est pas aussi "lisse", autant optimisé et aussi bien intégré qu'iOS, mais tant pis.

ForceRouge

100% d'accord avec tes deux derniers messages. Apple est un gamin capricieux a qui on dit qu'il a suffisamment tiré sur la corde.

A l'époque Jobs, Apple était une boite d'enflure, mais qui essayait de garder un semblant de bon copain en dosant ce qui rentre et ce qui sort pour que les gens soient content tout en s'en mettant plein les poches. C'est "fair".

Maintenant à l'époque Cooks, c'est fini, c'est juste devenu une boite de raclure. Le premier prix est à 1000€, l'OS est toujours aussi fermé, Apple garde le contrôle sur absolument tout, dès que tu veux sortir de l'écosystème apple, c'est la merde: filtre photo et angle de rotation en metadata spécifique apple, pas d'accès en mode fichier à travers l'usb, ou alors juste les photos dans des dossiers nommé n'importe comment, toujours pas possible en 2024 de mettre un simple icône en bas de l'écran, l'arrivé enfin de l'usb-c après des années à se gaver sur les royalties lightning, et maintenant la fin des PWA...

D'ailleurs, comment ils savent que les PWA ne sont pas utilisées? Je croyais que le respect de la vie privée était leur priorité.

Plus globalement, Apple et Google ne payent pas (ou très peu) d’impôt et n'apportent donc aucune richesse à la France/Europe. On s'adapte et joue a peu prêt avec les même arguments que Apple envers Spotify. Si Apple n'est pas content, ils ont cas arrêter de vendre en Europe. Ca nous poussera à être créatif.

A titre plus perso, j'ai toujours alterné entre iOS et Android depuis que ca existe, mais je pense que c'est fini pour moi. Android a su s'améliorer en prenant ce qu'il y avait de bon dans iOS (principalement: gestion fine des permissions, patch de sécu de l'OS sur au moins 5 ans). Alors qu'iOS n'a fait que verrouiller de plus en plus. Android n'est pas aussi "lisse", autant optimisé et aussi bien intégré qu'iOS, mais tant pis.
Tu soulignes un point crucial sur la contribution à l'impôt oui !
Même si ça ne concerne pas qu'Apple, c'est extrêmement dérangeant.

Edit : ce sont toutefois les champions en valeur manifestement, loin devant tout le monde.
https://en.wikipedia.org/wiki/Ireland_as_a_tax_haven

J'aimerais pouvoir avoir la force (rouge) d'abandonner iOS.
Peut-être au prochain renouvellement, que j'espère le plus tardif possible.
S'il y a bien un aspect positif qu'il faut leur reconnaitre, c'est qu'un iPhone dure.
Modifié le 29/02/2024 à 18h10

Historique des modifications :

Posté le 29/02/2024 à 18h07


Tu soulignes un point crucial sur la contribution à l'impôt oui !
Même si ça ne concerne pas qu'Apple, c'est extrêmement dérangeant.

J'aimerais pouvoir avoir la force (rouge) d'abandonner iOS.
Peut-être au prochain renouvellement, que j'espère le plus tardif possible.
S'il y a bien un aspect positif qu'il faut leur reconnaitre, c'est qu'un iPhone dure.

Le fond du DMA et du DSA est justement de dire que certaines entreprises sont tellement grosses et importantes que l’autorité publique peut leur imposer des contraintes de cette nature sur leur produit.

Jean de Tolbiac

Le fond du DMA et du DSA est justement de dire que certaines entreprises sont tellement grosses et importantes que l’autorité publique peut leur imposer des contraintes de cette nature sur leur produit.
Elle peut imposer des contraintes d'accès et d'interopérabilité. Mais peut-elle imposer des contraintes de maintien d'une fonctionnalité ? C'est ça la question qui se cache derrière.
Chose assez surprenante, la fin des PWA ne concerne que les iPhone, elles continuent de fonctionner sur iPad sur la beta 4. On espère que ça restera comme ça pour la version finale.
L'iPad n'est pas concerné par le DMA il me semble à cause d'un moins grand nombre de produits que pour l'iPhone.
Je dis ça de mémoire et j'ai la flemme de chercher la confirmation.
On est d'accord que les PWA dont on parle sont les applications "installées" depuis le site WEB directement et non les apps WEB compilées et mises à disposition sur l'Apps Store ?
Oui, c'est ça.

fred42

Oui, c'est ça.
Merci, c'est rassurant :D
Un très bon article anglophone pour comprendre pourquoi Apple agit comme ça avec le DMA: https://www.macstories.net/stories/understanding-apples-response-to-the-dma/
Très bon article en effet.
Finalement, les PWA restent disponibles en Europe. Mais uniquement avec WebKit https://arstechnica.com/gadgets/2024/03/apple-changes-course-will-keep-iphone-eu-web-apps-how-they-are-in-ios-17-4/
Grillé par Ferd !