Notably, these web apps will "continue to be built directly on WebKit and its security architecture", so a progressive app added to the Home Screen can't for example run on a Chrome engine.
Yeah, that is interesting to me. I would imagine one of the main reasons people have been asking for alternative browser engine support in the first place is the potential to have more features added to PWAs by competing platforms, since they were clearly not a priority in WebKit for a very long time.
> To me, this is an example of the vagueness of the Digital Markets Act. Reading between the lines, it sounds like Apple thought
No. It's a lie. The only thing Apple is thinking is all the ways it can weasel out of DMA, and how far it can push. That is it.
Nothing in the DMA says that Apple can't provide PWAs. And the only reason Apple reverted the decision they already communicated is because for now it damages its brand more than making this move.
> Nothing in the DMA says that Apple can't provide PWAs
Not specifically. Apple is just forced not to gatekeep functionality. My suspicion is that the problem is that Apple doesn't want to grant anyone but themselves the ability to install a new app icon onto the home screen.
Chrome and Firefox can't make equivalent PWAs without such an API, especially not if they also need certain background execution exemptions to keep ServiceWorkers active at the right times. This would violate the DMA.
The nice solution would be to expose certain APIs to apps with certain permissions (requiring some explicit user consent, if required, though Safari would require the same consent in that case) so that other apps can do normal PWAs. The shitty, angry toddler approach would be to take away all PWAs and say "well then I guess NOBODY CAN HAVE THIS, _MOM_". Apple seems to have applied the latter strategy.
Interesting enough, Android has the same limitation: Chrome can add "apps" to the system, but other browsers don't have the same capabilities.
If Apple's PWAs are deemed unacceptable because Chrome can't implement them, I would expect Google's Android PWAs will be unacceptable for the same reason.
> o me, this is an example of the vagueness of the Digital Markets Act. Reading between the lines, it sounds like Apple thought it couldn’t offer WebKit-powered Home Screen apps in the European Union because of the DMA’s guidelines on browser equality.
> Apple clearly interpreted the guidelines as meaning it had to offer PWA support for alternative browser engines in order to keep offering the feature for Safari and WebKit.
> In the two weeks since the initial announcement, and the associated pushback, Apple came to the realization – one way or another – that it was mistaken. Whatever the backstory is, I’m glad Apple listened to the feedback and reversed course on this one.
God, what a pathetic take.
May apple be fined into the ground for their continued arrogance. This is not a solution. This is still gatekeeping.
This is a standard negotiating tactic, right? Ask for something really difficult AND for something entirely unacceptable. Then, after pressure is applied, drop the entirely unacceptable demand and "show your flexibility". And there you go, you made a concession, now the other party must make a concession ...
9 comments
[ 5.0 ms ] story [ 34.8 ms ] threadNo. It's a lie. The only thing Apple is thinking is all the ways it can weasel out of DMA, and how far it can push. That is it.
Nothing in the DMA says that Apple can't provide PWAs. And the only reason Apple reverted the decision they already communicated is because for now it damages its brand more than making this move.
Not specifically. Apple is just forced not to gatekeep functionality. My suspicion is that the problem is that Apple doesn't want to grant anyone but themselves the ability to install a new app icon onto the home screen.
Chrome and Firefox can't make equivalent PWAs without such an API, especially not if they also need certain background execution exemptions to keep ServiceWorkers active at the right times. This would violate the DMA.
The nice solution would be to expose certain APIs to apps with certain permissions (requiring some explicit user consent, if required, though Safari would require the same consent in that case) so that other apps can do normal PWAs. The shitty, angry toddler approach would be to take away all PWAs and say "well then I guess NOBODY CAN HAVE THIS, _MOM_". Apple seems to have applied the latter strategy.
Interesting enough, Android has the same limitation: Chrome can add "apps" to the system, but other browsers don't have the same capabilities.
If Apple's PWAs are deemed unacceptable because Chrome can't implement them, I would expect Google's Android PWAs will be unacceptable for the same reason.
> Apple clearly interpreted the guidelines as meaning it had to offer PWA support for alternative browser engines in order to keep offering the feature for Safari and WebKit.
> In the two weeks since the initial announcement, and the associated pushback, Apple came to the realization – one way or another – that it was mistaken. Whatever the backstory is, I’m glad Apple listened to the feedback and reversed course on this one.
God, what a pathetic take.
May apple be fined into the ground for their continued arrogance. This is not a solution. This is still gatekeeping.