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

[LAwLz]

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

Source on the APIs changing? Which APIs are we even talking about here? Server-side or client-side?

Just because the browser gets updated doesn't mean the APIs change. 

 

 

I get the impression that you don't know how these things work, but are trying to come up with reasons why it would be difficult for Apple to implement these changes. Since we already have a proven system that works (Safari), the only argument left seems to be "if they make it open to everyone then they can't change it all the time". That argument only holds water if we assume that the API does change a lot (which we have no evidence of, and it doesn't on any other platform including Apple's own MacOS) and if we assume that a constantly changing API would be a big issue.

 

I find it weird that you say Apple, the biggest tech company in the world, couldn't keep the ABI stable when it isn't an issue for anyone else. Are Apple's developers really that incompetent compared to everyone else? I find that hard to believe. 

I think it sounds more believable that they are using this as an excuse to:

1) Get some petty revenge on the EU for forcing them to open up their walled garden a bit.

2) Restrict user and developer freedom now that they were forced to loosen the lease a little bit.

 

I don't think that the APIs change a lot like you try and claim they do. The reason I don't believe that is because that would also require changes on the APN, and since it has to be backwards compatible with users that haven't updated, and retain compatibility with the PWAs, it is already restricted in several ways. It just doesn't make sense to assume that these things change a lot when they rely on a long chain of processing that also needs to be backwards compatible and that third-party developers has to access. These are the realities that we already live with, because Safari supports PWAs as it is today. These challenges are not something new that would suddenly appear because third-party browsers got access to the Push and notifications API, or got the ability to run service workers.

 

 

2 hours ago, hishnash said:

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. 

I think that's a much better argument, "usage is low and Apple don't want to put in the work". I think that's far closer to the truth than "Apple does this to protect everyone, because letting other browsers run PWAs would be a security risk". 

 

 

2 hours ago, hishnash said:

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. 

Who said anything about Goole bypassing APNs? Everything I have said so far talks about Chrome getting notifications from APNs. 

You keep coming back to this scenario that nobody else but you are talking about. It almost feels like a strawman argument because it is totally irrelevant to the conversation and idea I am putting forth. You might as well say "yes, but what if we let Chrome get root privileges and do whatever it wants? Then it would be a security risk".

But let's humor the idea that letting Chrome run PWAs on iOS would result in Chrome being able to bypass Apple's notification service. What would it actually result in? Google might be able to get the IP of an iPhone user? Oh, scary... What an invasion of privacy that would be... As if that isn't already the case. Please keep in mind that the push notification system for PWAs is an open standard from the W3C which has already thought of the privacy implications, which is why endpoints are always unique and random and there is permission control built in.

Please keep in mind that a lot of these services already run on Google's cloud service. There is an argument to be made that letting websites directly push notifications to the users' devices could result in higher privacy because instead of the workflow looking like this:

Web service -> Google's service -> Apple's APN -> End user

the flow would look like this:

Web service -> Google's service -> End-user

 

As things are today, a lot of times it is a Google service that contacts Apple's APNs.

A lot of apps also already use FCM to push notifications to iOS apps.

 

 

All of these "security concerns" are things we already live with. The idea that it would open up new threats is utter bollocks. Apple might want you to believe that they always do things because of security and privacy reasons, but in reality, it's just an excuse for not doing things that could give their users some more freedom at the expense of them losing some control. 

[Kisai]

On 2/16/2024 at 7:28 AM, HenrySalayne said:

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

 

 

Again, look at MSIE.

 

Every bloody Asian MMO uses the system webview (MSIE) up until Microsoft removed it. The software I used at the telecom company and the software I used at the auction company, were married to MSIE. Yes, firefox was installed on the computers, but attempting to run any of that web-based stuff on firefox would just break and barely get past the login page in nearly every situation. The Siebel stuff was just absolute garbage, and it was just one giant activex app.

 

The engineering company I did some work for, still needed Java, Silverlight and Flash, in 2020.  These only still work in MSIE. Adobe timebombing flash absolutely caused problems. 

 

MSIE was the only expected web browser on Windows up until Chromium based Edge. 

 

On both Windows and Mac, you never "replaced the system webview" you just ran a separate browser. Thus we have the situation where there are now 30 applications running 30 different versions of CEF (Chromium Embedded Framework) instead of them all using the same version, the most recent version.

 

But on iOS and Android, you can quite literately replace the system webview because the devices aren't desktops, only the task that is in the foreground is ever running, barring some exceptions that require access to other API's that you don't get by being a "web page" only a "web app" or native app.

 

Web apps on iOS have to use the system webview, and all the applications that are designed to use the web view, expect the API that web view exposes. If you suddenly replace the Safari DOM with Firefox or or Edge's DOM, those applications are going to break.

 

[jagdtigger]

4 hours ago, Kisai said:

Web apps on iOS have to use the system webview, and all the applications that are designed to use the web view, expect the API that web view exposes. If you suddenly replace the Safari DOM with Firefox or or Edge's DOM, those applications are going to break.

Its  like there isnt a standard that every single one of them supports....... /s I thought devs learned their lesson from the IE debackle but guess i was wrong.

[hishnash]

7 minutes ago, jagdtigger said:

Its  like there isnt a standard that every single one of them supports....... /s I thought devs learned their lesson from the IE debackle but guess i was wrong.

There is no standard when it comes to the api you use to take to a web view from c.

There is a standard on how you write JS, CSS and HTML (not that all browsers follow this exactly) but there is no standard at all when it comes to the api you use in the native part of the app to talk to the web view, be that in swift, obj-c, c/c++ etc this is different (very differnt) for each web-view. Some web-views run in-prosses, other run as seperate child prosses with shared memory others run as completely detached seperate sandboxed were you talk to them through a fully async XRPC interface. And each browser had drastically differnt hooks native apps can attach to. 

[Kisai]

1 hour ago, hishnash said:

There is no standard when it comes to the api you use to take to a web view from c.

There is a standard on how you write JS, CSS and HTML (not that all browsers follow this exactly) but there is no standard at all when it comes to the api you use in the native part of the app to talk to the web view, be that in swift, obj-c, c/c++ etc this is different (very differnt) for each web-view. Some web-views run in-prosses, other run as seperate child prosses with shared memory others run as completely detached seperate sandboxed were you talk to them through a fully async XRPC interface. And each browser had drastically differnt hooks native apps can attach to. 

Here's something to try. Download ANY RPG MAKER MV game. Any of them.

 

Now swap the included old version of nw.js with the most recent version.

Note the date

 

Now what happens if I just try to load it in chrome?

Same happens with Firefox and Chromium Edge. Now if you don't know why it does this (hint web browser permissions) you might write it off.

 

But what if I load it in the current nw.js?

no dice either.

 

In fact chrome tells you exactly what the problem is:

 

Still, if you're not sure how to make this work, you have to distribute it with the old nodejs chromium version. Likewise, MV games are supposed to work on mobile devices, and do... sometimes. See those first two warnings in google chrome. 

 

Safari, Firefox and Chrome don't all play the same formats, so if you're hosting it on a website to be played, you need to have duplicate assets for every browser/webview.

 

And we're right back to the problem of why the OS webview ends up being the least worst option, because you have no idea if some other browser will work at all.

[jagdtigger]

1 hour ago, hishnash said:

There is no standard when it comes to the api you use to take to a web view from c.

There is a standard on how you write JS, CSS and HTML (not that all browsers follow this exactly) but there is no standard at all when it comes to the api you use in the native part of the app to talk to the web view, be that in swift, obj-c, c/c++ etc this is different (very differnt) for each web-view. Some web-views run in-prosses, other run as seperate child prosses with shared memory others run as completely detached seperate sandboxed were you talk to them through a fully async XRPC interface. And each browser had drastically differnt hooks native apps can attach to. 

At that point you might as well better off making a native app and skip the middleware.........

[Salted Spinach]

This video explains whats going on.

Besides the clickbait title and bad haircut

 

[Caroline]

Well that's how it is.

 

 

[paeschli]

Is iOS 17.4 already out? Mine says 17.3.1 is still the latest version

[LAwLz]

Update:
Apple changed its mind. Although the web apps will still use WebKit even if you set a different browser as your default.

 

https://developer.apple.com/support/dma-and-apps-in-the-eu

 

Quote

Previously, Apple announced plans to remove the Home Screen web apps capability in the EU as part of our efforts to comply with the DMA. The need to remove the capability was informed by the complex security and privacy concerns associated with web apps to support alternative browser engines that would require building a new integration architecture that does not currently exist in iOS.

 

We have received requests to continue to offer support for Home Screen web apps in iOS, therefore we will continue to offer the existing Home Screen web apps capability in the EU. This support means Home Screen web apps continue to be built directly on WebKit and its security architecture, and align with the security and privacy model for native apps on iOS.

 

Developers and users who may have been impacted by the removal of Home Screen web apps in the beta release of iOS in the EU can expect the return of the existing functionality for Home Screen web apps with the availability of iOS 17.4 in early March.