3 ms·

> The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally. This is a silly and thin technicality,

> The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally. This is a silly and thin technicality, and not at all the same as what people are mad about. Nobody cares that WebKit is used to render certain windows on iOS and MacOS - it's Apple's choice to implement first-party programs that way. They can defend their usage of it internally, the problem is the limitations they impose on competitors. > I’ve read the DMA You're certainly taking some elements in liberty. It remains unclear how defining WebKit as a "PWA runtime environment" exempts it from the terms of the DMA or DSA.

layer8 3y ago
Sorry, but at this point it’s you who have to provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing. Just to be clear, I’m absolutely in favor of having a free choice of PWA engines, I just don’t see this being implied by the DMA and the present gatekeeper designations. The question really is how a PWA runtime environment differs in principle from the regular iOS app runtime environment, which the DMA also doesn’t mandate to be replaceable.
- smoldesu 3y ago
  > provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing. Oh, this is easy. First-party software is distributed by Apple. They choose how that software is presented because they are the operator of the software. PWAs and websites are distributed by third-parties. They are websites, not curated by Apple, that load in your browser. It's only after you use your browser's "PWA" function (something everyone should have) that we change into this "WebView" scenario. It's arbitary, and not at all the same as Apple rendering Apple Music or Settings using WebKit. > how a PWA runtime environment differs in principle from the regular iOS app runtime environment A PWA is packaged by the user. If Apple's "solution" is forcing all apps to display PWAs in a Safari WebView, then yes, the DMA will target it as a core service. I don't see why the EU would roll over when they made specific carveouts for browser control in the DMA.

layer8 3y ago

Sorry, but at this point it’s you who have to provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing. Just to be clear, I’m absolutely in favor of having a free choice of PWA engines, I just don’t see this being implied by the DMA and the present gatekeeper designations. The question really is how a PWA runtime environment differs in principle from the regular iOS app runtime environment, which the DMA also doesn’t mandate to be replaceable.

smoldesu 3y ago
> provide a compelling explanation of how the way iOS runs PWAs constitutes a use of Safari, or of web browsing. Oh, this is easy. First-party software is distributed by Apple. They choose how that software is presented because they are the operator of the software. PWAs and websites are distributed by third-parties. They are websites, not curated by Apple, that load in your browser. It's only after you use your browser's "PWA" function (something everyone should have) that we change into this "WebView" scenario. It's arbitary, and not at all the same as Apple rendering Apple Music or Settings using WebKit. > how a PWA runtime environment differs in principle from the regular iOS app runtime environment A PWA is packaged by the user. If Apple's "solution" is forcing all apps to display PWAs in a Safari WebView, then yes, the DMA will target it as a core service. I don't see why the EU would roll over when they made specific carveouts for browser control in the DMA.