Hacker News Reader

This is in fact how PWAs work on iOS. They do not run in Safari at all, but in a special runtime called Web.app, which is coded to use WebKit. Safari doesn’t have the ability to do the things the PWA runtime can do. Letting other browsers “run PWAs” would not be a matter of exposing an existing private API, it would require creating a a brand new plugin API for Web.app that would allow inserting other browser engines into it.

Surely the distinction is about the existence of a market. There is a market for competing browsers from different vendors which do compatible/interchangeable things that might be selected by different consumers for different reasons. The technical definition isn't the important bit, the regulation exists to preserve that interplay between consumer choice and market innovation.

There is no such consumer-driven market for in-app UI libraries, be they WebKit-based or not. The "consumers" in such a market would be the app vendors, and in fact this is an area well-served by existing products from competing vendors. That's clearly not what the DMA is trying to regulate.

It's because those apps are not core platform service. Safari and iOS both are core platform services, which are explicitly designated as a target of this regulation. Go read the actual wording and have some understanding before making this kind of assumption.

When you open a PWA, Safari does not appear. The argument can be made that this is not Safari, but a PWA runtime environment that happens to use WebKit internally. Basically, the PWA is it’s own separate app (i.e. not Safari) that is being run by iOS with the help of WebKit, similar to how other OS features also use WebKit internally. It is not clear at all that this would fall under the category “web browser engine” of the DMA, since using a PWA does not constitute browsing the web.

As for your argument about core platform services, the app store is a core platform service and (I’m pretty sure) uses WebKit internally, at least for some of its pages in login and payment flows, and similar for various iCloud-related functions accessible from Settings.

I’ve read the DMA, you don’t have to be condescending.

I'm not sure if you've only read some digests but not the full text including other supporting materials (it matters since this defines how the laws will be applied) since all you mentioned are already addressed in the designation decision doc. To be specific, in DMA.100027, EU clearly stated that it doesn't matter whether it's embedded in other apps or standalone:

  > "... the Commision concludes that Safari, including all the elements that allow for the display and access to web content, either standalone, integrated or embedded in other software applications or similar, constitutes a web browser CPS ..."

If you've seriously worked on hashing out all the details of CPS and clearing up the ambiguities, you cannot be unaware of this decision since this will impact everything on your daily works. Yeah I did that because the precise definition of CPS was critical for my work in the last year.

EU is not that dumb, to my understanding they've been pretty serious in respecting the spirit of this specific legislation. You cannot say that some part of it can be simply opted out by adjusting the definition of your product. What they care about is how business is done and make the market control out of it.

> 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.

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.

> 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.