Thoughts on Apple's EU-PWA dilemma

For a “small number of users” it was the biggest controversy of the upcoming iOS 17.4 update that’ll bring lots of changes to be in compliance with EU’s DMA. What happened in short:

• up until now 3rd party browsers have to use Apple’s WebKit engine on iOS
• Apple has to open iOS for 3rd party browser engines
• as a result Apple announced it’ll disable support of PWAs (Progressive Web Apps) in the EU for any browser on iOS, even on it’s own Safari¹
• EU said it’ll start an investigation if that happens
• Apple announced that it’ll roll back the change¹

At first glance the announcement of killing PWAs for EU users seemed completely unnecessary and some even argued that Apple is just plain evil of doing so. Lets explore the possible problems and implications of this change and why it’s much more likely that this is the result of not so good design choices in the past rather than Apple just being mean.

⚠️ I’m obviously not an Apple engineer so this is guess work but given the arguments of Apple I think it’s not so far from the truth.

Whats a PWA in a nutshell?

A PWA (in full “Progressive Web App”) is basically a webpage which behaves like an app, it has it’s own storage / permissions, can do background tasks (for example to receive push notifications). It optionally can be installed to the device and looks and feels like an native app. It gains offline functionality, runs in full-screen without any browser elements visible and also has more persistant storage for example. Under iOS a PWA only gets all the functionality if it’s installed, that’s the reason it’s all about that specific feature. For the sake of simplicity in this text the term PWA refers to installed PWA, also if technically spoken a PWA can also exist just in the browser.

Apple’s problems, actions and statements

According to the EU DMA Apple has to open iOS for 3rd party browsers and also allow that those browsers can use their own engine so that there can be real competition to Safari. Some refer to Apple’s Safari as the new Internet Explorer and despite the fact that Apple recently put much more efforts into the development it still lacks features compared to Chrome or browsers that derived from it. The problem for Apple is that on iOS now all browsers have to be treated equally. Apple is not allowed to prohibit other browser providers from having access to the same features that Safari has access to and therefore other browsers must also be allowed to install PWAs. Apples WebKit is the standard browser engine used by the system, that implies if another browser than Safari is set as default also installed PWAs should run in the browser engine of the set default browser.

So Apple deactivated PWA support for EU users in the current developer versions of iOS 17.4. And issued a statement that this is intentional. Apple argues that PWA support provided by other engines is potentially unsafe and that it can’t assure that installed PWAs only can see their own data and all permissions are handled correctly. Another argument of Apple is that it’s possible that a PWA fakes other apps to phish for user data or credentials. When I see some not so tech savvy people in my circle installing shady apps and / or getting confused by their phones or it’s eco system that argument makes sense to me. I think the point here is that Apple trusts Safari but doesn’t necessarily trust any other app which categorizes itself as browser. Apple also says that this will need a complete rework of the permission and storage handling for PWAs which doesn’t exist in iOS and that the number of users which will be affected by this change will be (as usual) just “a small number” and that it isn’t worth the effort.

That caused drama because obviously developers and their work depend on the compatibility provided by the platforms and iOS would basically be the only but at the same time one of the most important platforms to drop PWA support for a around ~150 million possible users² directly on system level. That almost immediately triggering a statement by the EU that if it happens they will investigate it.

So on 2024/03/01 Apple released a new statement that they won’t disable PWAs in EU but that the only way to do this is that PWAs still run on WebKit and not on the engine of the browser which is currently set as default.

It’s most likely a design problem

The feature to add a webpage to the home screen is present since iOS 1.1.3 (at least). This was a time where no web standards for accessing things like gps location, camera, etc. existed. So from Apple’s point of view adding a webpage to the home screen was just like a bookmark but with a nicer icon, there was no need to think about permissions, storage, sandboxing and so on. Then over time it became necessary to manage stuff like that and Apple has done the thing that all providers of closed systems do, they assumed that Safari / WebKit will be be the one and only for all eternity. Much like Microsoft did when they integrated Internet Explorer so deep into Windows until they couldn’t really remove it anymore. So they made Safari and it’s WebKit the permission manager for webpages and also PWAs, which makes sense because Safari obeys the permissions it gets from iOS and since Apple trusts Safaris permission management there is no issue, until there is. The decision by Apple to solely rely on Safari / WebKit for manage pages added to home screen made sense at the time it was introduced but to build all the permission handling on top of it was most likely a mistake. But there is more to it because permission handling for PWAs always felt a bit strange UX wise on iOS. Somehow notifications are the only permission which is more or less visible in the iOS settings. For example if I install a PWA for video calls it asks me every time if it’s allowed to use the camera but there is no way to allow it permanently. If i open the page in Safari I can access the website settings via the address bar menu and grant the permission permanently (well hidden) but it doesn’t change the behavior of the installed PWA since they are separated and since there is no way to access the website settings of the PWA there is also no way to grant this rights permanently. From an UX standpoint that makes using PWAs much more annoying compared to native apps. To conclude this, it totally makes sense to manage website permissions inside the browser but as soon as a webpage can be installed as PWA this approach becomes problematic and it would’ve been wise to rework it as soon as installing webpages which can act like an app became possible.

The dilemma

Now, what can Apple do and what is feasible to do? I think there are basically 4 options and each has it’s tradeoffs.

1. Just do it right: From a technical perspective Apple should delegate the permission management of PWAs to the OS instead of Safari. I believe the Apple statement that this is a significant change and will most likely take some time to implement. Also most people I know haven’t used PWAs even once on their mobile, regardless if Android, iOS, tech savvy or non tech savvy user. I’m using some PWAs on iPadOS and MacOS but on iOS I only used Elk for some time and even while it’s a really good PWA (🙂) I prefer native alternatives. So to me Apple’s argument that it’ll only effect a small number users is sadly most likely true and the cost of implementing this would be probably very high compared to the number of users which will benefit from it.
2. Let the browser manage it: As I already stated that would come at the cost that the OS just trusts the current default browser. That’s certainly not a problem in case of Chrome, Firefox etc. but since the beginning of the mobile app era there where apps that call itself “Flashlight” but does other stuff in the background ³. What if a user with far less tech knowledge downloads an app which under the hood acts as a browser and at some point create a PWA on the home screen to fake a banking app for example. So all in all this would be a much worse option. Also there are edge cases like what happens if the user decides to change the default browser after a PWA is installed? What happens to it’s storage and permissions? Should all the info handed over to the new default browser? I doubt that that’s a good idea.
3. Disable PWA support in EU: Not spending much time here, thats probably the worst option for everyone. It may be the cheapest solution for Apple in the short-term but will definitely come at the cost that a web developers will treat Safari even more as second citizen as they (understandably) already do. Also EU could argue that that’s done to control the iOS app ecosystem even more than they already do.
4. Only allow PWAs via WebKit: That’s the latest approach Apple proposed but is currently not released for testing. On the one side browsers now can use there own engine, EU mission accomplished. On the other side they can’t use it for installed PWAs. That means that if a feature only works in Chrome and it’s engine it may not work after a PWA is installed via Chrome since it now uses the WebKit engine. Also we will see what EU has to say about this, if EU says Apple has to support 3rd party engines also for PWAs Apple hopefully bites the sour one and implement the critical parts like permission management of PWAs on system level.