iOS 17.4 Kills Web Apps in the EU - You can no longer install PWAs on Apple devices

[creat0r]

Summary

For EU users, iOS 17.4 removes the ability to install PWA (Progressive Web Apps) on Apple devices. This change rolls out among a long list of other changes to comply with the EU’s recent rulings, forcing Apple to open up their platforms to third-party stores for apps, web browsers etc. Apple is therefore making these changes in accordance with this the European Union's Digital Markets Act (DMA).

 

Quotes

Quote

 […] the web app opens like a bookmark, with no dedicated windowing, notifications, or long-term local storage. - Macrumors

 

My thoughts

 It sucks that they do this since I use it. Probably a tactic to make using anything but a real native app a horrible experience. And since using third-party app stores seems like it’ll be a major headache for the average user, this will just force even more users to use Apple’s App Store.

 

Sources

 https://www.macrumors.com/2024/02/08/ios-17-4-nerfs-web-apps-in-the-eu/

[OhYou_]

you just know there are thousands of businesses that rely on this for internal "apps" their employees use daily on company phones.
It's depressing just thinking about the situation so many people like me are in right now, tons of retraining and handholding for users.
on the surface you would think whatever it now opens in safari instead of a full borderless window, but no its not that simple and many users will struggle with the change. no more notifications either I think, rip

[ieleja]

name 5-10 PWAs, that we use on daily base, please! (read macrumors article, wikipedia and so, but not get point)

thanks!

[LAwLz]

7 hours ago, creat0r said:

Apple is therefore making these changes in accordance with this the European Union's Digital Markets Act (DMA).

Just to be clear, the DMA has nothing to do with Apple removing support for PWA. They could keep supporting that and still comply with the DMA. 

 

Apple never really cared for PWAs, probably because they prefer native apps that have to comply with their restrictions. 

 

But I am not surprised by this move since Apple never fully implemented PWA and left it without support for things like notification support and it has quite limited access to storage. They were never really serious about supporting it. 

[tim0901]

Yeah, Apple could implement a system that allows 3rd party browsers to be used for PWA (as that's fundamentally the problem - they currently always use Safari, with no way to direct them to another browser). They just don't want to put the effort into developing such a solution.

[Senzelian]

17 hours ago, OhYou_ said:

you just know there are thousands of businesses that rely on this for internal "apps" their employees use daily on company phones.

Yup, we use a huge amount of PWAs. Luckily I just switched from a company iPhone 13 to a Pixel 7 Pro and more and more people are willing to give Pixels a shot in the company.

 

Apple is really trying their hardest to kill their smartphones.

[Mark Kaine]

but that's the opposite of what these new rules require... again a bold strategy from apple, the fines will be funny ~

 

 

[jagdtigger]

Apple is a bitter loser, like a toddler having a tantrum lol........

[mecarry30]

Apparently it's a bug since some people still have their PWAs working.

Additionally, some are theorizing that since there currently isn't a framework/API for other browsers to make PWAs, Safari would have an unfair advantage if it had PWAs and other browsers like Chrome and Firefox didn't. But since this behavior is inconsistent, it could just be a weird-ass bug.

[hishnash]

4 hours ago, mecarry30 said:

 

Additionally, some are theorizing that since there currently isn't a framework/API for other browsers to make PWAs, Safari would have an unfair advantage if it had PWAs and other browsers like Chrome and Firefox didn't. But since this behavior is inconsistent, it could just be a weird-ass bug.

From what I have seen it looks like it is removed in the EU but the detection system to check if your in the EU has some false negatives. So you will get some people were it works as the system I snot 100% sure your in the EU or not. 

(they do not just use location).

 

Removing it makes lots of sense as building an api that would let third party browsers offer support for these in a way that does not expose users to un-expected privacy issues will take a LOT of work.  

[LAwLz]

13 hours ago, hishnash said:

Removing it makes lots of sense as building an api that would let third party browsers offer support for these in a way that does not expose users to un-expected privacy issues will take a LOT of work.  

How does letting other browsers use PWAs expose users to privacy issues that aren't already a possibility with PWAs running in Safari?

[RejZoR]

Aren't these apps just webpages posing as apps on a phone? It's like running a webpage, but without browser menus and navigation elements?

[HenrySalayne]

1 hour ago, LAwLz said:

How does letting other browsers use PWAs expose users to privacy issues that aren't already a possibility with PWAs running in Safari?

Safari is automatically siphoning all the tracking data and rerouting it to Apple for evaluation. This security measure would not be possible with any other browser.

 

I don't think you grasp the gravity of the situation and understand how hard this is for Apple. On the one hand, they need to annoy everybody as much as possible. They need to incite their user-base to them into useful idiots sharing and vocalising Apple's utter disapproval of the EU regulation. On the other hand, this cannot be too obvious or it might reflect badly on the brand. Removing PWAs is just tip-topping right on the edge between these two extremes -  perfection.

 

[LAwLz]

4 hours ago, RejZoR said:

Aren't these apps just webpages posing as apps on a phone? It's like running a webpage, but without browser menus and navigation elements?

There are some differences. They are apps written entirely in web languages, and they are executed inside a browser engine. So in that way they are just like web pages except they run inside their own browser instead of just a tab.

 

The difference is that they get access to more native APIs, like for example they can:

Cache data offline.

Send notifications.

Synchronize data in the background and can fetch data BEFORE it's needed (unlike regular pages that can only cache data after it has been fetched).

Respond to requests from other apps.

Access things like gyroscope data, and can display splash screens.

[hishnash]

8 hours ago, LAwLz said:

How does letting other browsers use PWAs expose users to privacy issues that aren't already a possibility with PWAs running in Safari?

In short the current api that apply exposed for third party browsers does not expose the needed bits to support PWAs. 

There is no way to register for notifications on behave of a PWA, there is no way to be worked up to run a PWA in the background. Or to schedule the ability to fire up in the background for a PWA.

The privacy concern would be that the third party browser might use the fact that it is running in the background to harvest more data about the user in a way users do not expect.  I think a proper api for PWA would need to have the same class for restrictions as the iOS keyboard extension apis that explicitly sandbox the keyboard extension from the parent app that provides it so that key strokes you enter in your banking app cant be read by the app that provided the extension.   However doing this as a PWA runtime is not going to be easy to figure out, including methods to share data to the PWA when it is created so that the user stays logged in etc. 

[LAwLz]

9 hours ago, hishnash said:

In short the current api that apply exposed for third party browsers does not expose the needed bits to support PWAs. 

There is no way to register for notifications on behave of a PWA, there is no way to be worked up to run a PWA in the background. Or to schedule the ability to fire up in the background for a PWA.

The privacy concern would be that the third party browser might use the fact that it is running in the background to harvest more data about the user in a way users do not expect.  I think a proper api for PWA would need to have the same class for restrictions as the iOS keyboard extension apis that explicitly sandbox the keyboard extension from the parent app that provides it so that key strokes you enter in your banking app cant be read by the app that provided the extension.   However doing this as a PWA runtime is not going to be easy to figure out, including methods to share data to the PWA when it is created so that the user stays logged in etc. 

I am not sure I understand what you mean.

 

Are you saying that a third-party browser would get installed, and then it would install a PWA running inside itself to gain more privileges?

I don't really understand what concern you see that would be unique to third-party browsers that isn't already a concern with Safari assuming third-party browsers got access to the same APIs as Safari currently uses.

[hishnash]

18 hours ago, LAwLz said:

I don't really understand what concern you see that would be unique to third-party browsers that isn't already a concern with Safari assuming third-party browsers got access to the same APIs as Safari currently uses.

Correct but apple has not written the needed apis that would let them do this yet and doing that correctly might well take a lot of work (for apples own apis they do not need to put in the same level of rigour as they can update safari whenever they update the os so do not need to consider needing to support them for more than this single point release, but public apis will need to stay ABI stable for a long time even if the api needs to change or have fixes).

For example to support push notifications a third party browser would need a new APNs api that would let them register tokens for each domain name PWA so that notification rate limiting was done per website and not at a global browser level.  Without this api they would need to instead set up thier own service that runs all the time in the background connected to their CDNs ... while google would love chrome to do this it would be a user privacy nightmare from the perspective of exposing apraoch IP location and ping time to googles network (google can get a very good idea of your location with this alone). 

 

So until such apis are written the only choice apple has is it pull the PWA feature form the EU as the EU law only requires apple to provide the same features as thier gatekeeper labeled aps/os features, it does not require apple provide access to the system to let a third party browser do anything more than safari.  This is also why the third party browser api is rather complex as it includes all the needed apis so that third party safari browser extensions that currently existing on iOS would be able to work with a third party browser, this is not just a runtime flag that lets you fork your prosses and call into JIT produced memory regions.   

[HenrySalayne]

1 hour ago, hishnash said:

For example to support push notifications a third party browser would need a new APNs api that would let them register tokens for each domain name PWA so that notification rate limiting was done per website and not at a global browser level.  Without this api they would need to instead set up thier own service that runs all the time in the background connected to their CDNs ... while google would love chrome to do this it would be a user privacy nightmare from the perspective of exposing apraoch IP location and ping time to googles network (google can get a very good idea of your location with this alone). 

Oh, no, you are right. Modifying the existing API to allow it to register PWAs for push notifications instead of the browser itself would take probably decades to develop. It's not like any browser on this planet has a per website push notification system already in place...

 

2 hours ago, hishnash said:

So until such apis are written the only choice apple has is it pull the PWA feature form the EU

"only choice". Sure...

You probably have an article from Apple explaining this in detail? Or is this just your opinion?

[Kisai]

On 2/13/2024 at 2:14 AM, tim0901 said:

Yeah, Apple could implement a system that allows 3rd party browsers to be used for PWA (as that's fundamentally the problem - they currently always use Safari, with no way to direct them to another browser). They just don't want to put the effort into developing such a solution.

More like "can't"

 

If you allow the system webview to be replaced then any application that uses the webview is impacted.

 

Honestly, does anyone seriously believe we're not reliving the MSIE 4.0 bundling nightmare that resulted in MSIE 4-8 required being installed because business vendors only build their activex crap to run on it? I'm sure companies like AT&T and Siebel were crapping their pants when Microsoft switched to Edge since all their stuff was proprietary "requires MSIE" hell. Hell there are still banks using Java. (not Javascript, Java, the plugin)

 

Everything is fine when everyone builds to a standard, and unfortunately Google swooped in and decided they wanted to set the standard by poaching Webkit from Apple, and then whines when Apple doesn't implement "their" stuff.

 

I just want a situation where I can rely on the OS to work as intended, and unfortunately this runs head first into political factors like consumer choice that says that the OS must treat all applications as equal, thus free avenues to developing on the OS (eg html 5+javascript) have to go away because the OS can't prefer it's own secured webview, and can't allow the OS webview to be overridden for OS components. Like imagine if you could replace the Edge webview on Windows 10/11 right now with Firefox? Every damn responsive web widget would end up broken. 

 

If anyone is at fault for this, it's Google. We shamed Microsoft for not updating MSIE to standards, until it fell so far behind that it gave up and borrowed Google's product. Yet Google is the one that keeps pushing pre-alpha quality features into the web browser and then changes and depreciates things for no apparent reason. Now imagine if that cruft was in the OS. 

 

I'm not saying Safari is great, but it's a known quantity that isn't beholden to Google's crappy behavior.

[hishnash]

5 hours ago, HenrySalayne said:

It's not like any browser on this planet has a per website push notification system already in place...

They do this by running a daemon at all times in the background.   

 

5 hours ago, HenrySalayne said:

You probably have an article from Apple explaining this in detail?

This is what apple told the press when asked why PWAs were removed (only in the EU).  

[HenrySalayne]

5 hours ago, Kisai said:

More like "can't"

 

If you allow the system webview to be replaced then any application that uses the webview is impacted.

 

Honestly, does anyone seriously believe we're not reliving the MSIE 4.0 bundling nightmare that resulted in MSIE 4-8 required being installed because business vendors only build their activex crap to run on it? I'm sure companies like AT&T and Siebel were crapping their pants when Microsoft switched to Edge since all their stuff was proprietary "requires MSIE" hell. Hell there are still banks using Java. (not Javascript, Java, the plugin)

 

Everything is fine when everyone builds to a standard, and unfortunately Google swooped in and decided they wanted to set the standard by poaching Webkit from Apple, and then whines when Apple doesn't implement "their" stuff.

 

I just want a situation where I can rely on the OS to work as intended, and unfortunately this runs head first into political factors like consumer choice that says that the OS must treat all applications as equal, thus free avenues to developing on the OS (eg html 5+javascript) have to go away because the OS can't prefer it's own secured webview, and can't allow the OS webview to be overridden for OS components. Like imagine if you could replace the Edge webview on Windows 10/11 right now with Firefox? Every damn responsive web widget would end up broken. 

 

If anyone is at fault for this, it's Google. We shamed Microsoft for not updating MSIE to standards, until it fell so far behind that it gave up and borrowed Google's product. Yet Google is the one that keeps pushing pre-alpha quality features into the web browser and then changes and depreciates things for no apparent reason. Now imagine if that cruft was in the OS. 

 

I'm not saying Safari is great, but it's a known quantity that isn't beholden to Google's crappy behavior.

I don't really follow your conclusion. Google, Microsoft and Apple alike have unnecessary proprietary BS in place. If they wouldn't hard-wire their browser implementation into their respective OSs as an essential part, we wouldn't have these problems.

How you decided that this is solely Google's fault is beyond me...

 

 

[hishnash]

7 hours ago, HenrySalayne said:

How you decided that this is solely Google's fault is beyond me...

 

What they are saying is that apps that used the embedded system browser were build (and tested) against that browser engine, they do not expect the embedded browser to change on them at runtime on the users device and if it did (regardless of what browser it would swap to) it would break basicly every single app. Since they way you talk to embedded chromium is very different to webkit and even more different to embedded Firefox.    Expecting all apps (including apps written 10 years ago) that use these apis to continue to work while the underlying browser engine is swapped on them is just absurd. 

Using the OS provided embedded browser is much much much better than embedded your own since your never going to bother shipping an update to your app every week as the browsers has its weekly security patches rolling out so if you embed a browser within your app your just creating sec nightmare for your users. Using the system browser provides a consistent (ish) ABI that you can target and means you do not need to become versed in browser security and the extra complexity that has. 

[LAwLz]

On 2/16/2024 at 5:27 AM, hishnash said:

Correct but apple has not written the needed apis that would let them do this yet and doing that correctly might well take a lot of work (for apples own apis they do not need to put in the same level of rigour as they can update safari whenever they update the os so do not need to consider needing to support them for more than this single point release, but public apis will need to stay ABI stable for a long time even if the api needs to change or have fixes).

What exactly do you mean by "same level of rigour"?

I really don't understand what you are trying to say here. Why can't Apple just let other browser developers access the same APIs Safari has access to? 

 

Are you saying that Apple wouldn't be able to keep the ABI stable because they constantly have to change things? Because I find that very hard to believe. Especially since no other OS, not even Apple's own MacOS has this issue. I feel like this is quite the ridiculous excuse that doesn't hold water.

By the way, ABIs don't have to be stable. The Swift ABI has been quite notoriously unstable until version 5 and yet everything was fine with that. 

 

Also, Apple is a very big company. They could figure it out if they wanted, if it was a real issue to begin with.

 

 

On 2/16/2024 at 5:27 AM, hishnash said:

For example to support push notifications a third party browser would need a new APNs api that would let them register tokens for each domain name PWA so that notification rate limiting was done per website and not at a global browser level.  Without this api they would need to instead set up thier own service that runs all the time in the background connected to their CDNs ... while google would love chrome to do this it would be a user privacy nightmare from the perspective of exposing apraoch IP location and ping time to googles network (google can get a very good idea of your location with this alone). 

I hope you realize that the functions to do this already exist and are already coded. It's just that Apple doesn't let anyone except themselves use it.

They don't need to develop a new API. They just need to let other developers use the same APIs they themselves use. All that about how Google could use this to track users is complete fear-mongering that isn't true at all. Apple just need to let Google do what Safari is already doing.

Also, these things are standards as defined by the W3C. Apple's APN servers already support it and it is already stable. If it wasn't then PWA's wouldn't work in Safari either.

 

It's the web apps that contacts Apple's APN which then pushes a notification down to the device. They could work exactly like it already does even if Apple allowed third-party browsers. 

Apple just needs to let third-party browser developers create a service worker that can subscribe to the push API that already exists in iOS.

Let me repeat that, all of these things already exist. It's just that Apple won't let other browser developers use it. They are artificially withholding features.

 

 

 

On 2/16/2024 at 5:27 AM, hishnash said:

So until such apis are written

They already are. How do you think PWAs work in Safari if they didn't have APIs for it?

[hishnash]

7 hours ago, LAwLz said:

What exactly do you mean by "same level of rigour"?

I really don't understand what you are trying to say here. Why can't Apple just let other browser developers access the same APIs Safari has access to? 

 

The api safari has access to will change (and do change) on every os update as apple ships a fresh build of safari with the OS. 

Public apis have a much higher burden of maintain to them than private apis that you can change at any point and that do not need the same level of security around them.   

 

7 hours ago, LAwLz said:

Also, Apple is a very big company. They could figure it out if they wanted, if it was a real issue to begin with.

 

Yes they could for sure, they could put in the work (like they did with the rest of the browser kit apis (that are rather exsteivq much more than people were expecting) but why bother when PWA usage is very low so removing the feature form safari is not that big an impact. 

 

 

7 hours ago, LAwLz said:

I hope you realize that the functions to do this already exist and are already coded.

I expect the current method does not bind them to the third party browser, eg have nested tokens. So that when the third party browsers tokens are revoked the child tokens are revoked... etc  I expect the existing apis in effect treat PWAs as apps without any decency on the browser. 

 

 

7 hours ago, LAwLz said:

All that about how Google could use this to track users is complete fear-mongering that isn't true at all.

If Google were to bypass using APNs and instead just run all the time in the background connected to firebase then they would be tracking you and that is not fear mongering at all. 

 

7 hours ago, LAwLz said:

Also, these things are standards as defined by the W3C

W3C does not define anything about how the message is delivered from the server to the device and to the running (or not running) application. It just defines the JS apis side of things.  

 

 

7 hours ago, LAwLz said:

The Swift ABI has been quite notoriously unstable until version 5 and yet everything was fine with that. 

You forget the solution to lack of ABI stability was inciting large amounts of the standard lib within your aps binary (or later shipping multiple ABI targets within the or for each swift version). 

 

[HenrySalayne]

56 minutes ago, hishnash said:

The api safari has access to will change (and do change) on every os update as apple ships a fresh build of safari with the OS. 

Public apis have a much higher burden of maintain to them than private apis that you can change at any point and that do not need the same level of security around them.   

That's a very poor approach to security. When Safari gets compromised, the APIs should not pose additional security risks. It doesn't matter if they are public or private.