While I too wish for better support for PWAs in iOS, the way push notifications are implemented in PWAs and iOS are fundamentally incompatible. iOS requires all push notifications to go through Apple's push server, which means there is only one long-poll connection to check and significant battery savings. Whereas, Google's PWA docs[1] literally lists random-push-service.com as the push server.

[1]: https://developers.google.com/web/fundamentals/push-notifica...

Safari on macOS already implements a proprietary web push technology using APNS. Push providers like OneSignal already support it.

It is 100% compatible with the way notifications work on iOS.

A long poll connection (i.e., a TCP connection not sending packets) uses exactly 0 joules of battery until something is sent.

That's not true. Long pools cannot have an indefinite timeout, especially for a mobile use case. Plus, it's not just the TCP connections. If you look at push notifications on Android phones in China, because GMS isn't available, every other app is having a background thread checking for push notifications. It adds up.

From that page:

> Each browser can use any push service they want, it's something developers have no control over.

The browser dictates the push service to use, not the developer of the web app. That URL is for the app developer to push content to.

I appreciate the frustration as a developer but as a user some of those APIs e.g. Push and Media Capture come with a lot of downsides.

I just checked Safari Desktop and I have well over 50 websites that I have blocked for Push Notifications. Many of which have no need to e.g. image site. But thankfully Apple has a polished, easily accessible UI for me to switch them off so not a huge deal.

On Safari iOS there is no Settings screen and not an obvious place to put one. You could put it under the main Settings screen but (a) nobody checks there and (b) it makes it confusing if you think of PWA as being a website still. And so you could end up with Push API being a feature that is hard to turn off. And that makes it a huge net negative for users.

Similar for the Web Capture API.

Ideally, PWAs added to the home screen would show up in the Settings app like normal iOS apps do. You would be able to control notification settings and privacy settings just like on any other app.

If they don’t want to allow web push for websites, that’s one thing, but crippling PWAs that users have chosen to add to their home screen is another thing entirely.

> Similar for the Web Capture API.

You can already use the camera through a PWA on iOS, until you add it to the home screen. Then, last time I checked, it stopped being able to use the camera or even ask for permission to use the camera, which really hurts the usefulness of PWAs.

The limitations are not entirely without reason, from my point of view. With app installation, there’s explicit consent involved — apps can never run unless I have requested such. On the web, all it takes is a redirect in an unexpected place to open an “app” that I want absolutely nothing to do with, at which point it’s free to slurp up all the unpermissioned data it wants.

That’s not to say that browser vendors have a bad track record when it comes to permission dialogs, but there’s still a ridiculous amount that they just hand over to sites without any prompt whatsoever.

This is easily fixable, however: just restrict the greater bulk of API access to “installed” PWAs, where the app runs in its own little easily manageable container with zero access to my main browser and specialized permissions UI.