I have not found a good use case for browser notifications, to the point that I have turned them off completely due to endless prompts for permission from every website to push them.

This is interesting for two reasons, firstly because the reason Chrome on Android has such terrible push notification latency is claimed to be the need to run the service worker in the context of the Chrome application, which being huge would use a load of battery so they avoid running it if at all possible.

Secondly, unfortunately the problem with iOS Safari notifications is once you get them working they cannot do things like group properly or replace each other. It just becomes a horrifying flood until you clear them all. If they have made iOS respect the tag and action fields, which are conspicuous by absence from their examples, then it will be game on.

I hope this is a sign that this is finally going to be working one day.

Let's see if I can figure this out...

"Declarative Web Push" is a web browser javascript API to subscribe to events from an HTTP server. It is similar to the "Web Push" API but changed to be better for mobile devices in a few ways.

Both the old Web Push and this new Declarative Web Push APIs use "the same Apple Push Notification service that powers native push on all Apple devices". I don't know if that means an Apple server actually listens for the notification from the HTTP server or if the device itself maintains the connection to the server.

It seems that for iOS this API only works on websites that are pinned to the home screen (i.e. not a notification from a site open in safari as a browser). These pinned websites work more like apps.

Is there something similar like this on Android? Either for pinned apps or from the browser? In other words, is there a reliable and efficient way to get notifications to an android phone without having to sign up for any service?

Still waiting for Alarms API to be implemented in web browsers to finally build my "Reminders" web app.

From an engineering and architecture perspective, I'm seriously disappointed at web notifications. They get abused by malicious or spammy threat actors a lot. The abuse potential was obvious from the start. Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?

For example, why can sites spam users with repeated push notification requests? why is there no active trust assessment and allow/block list maintained by browsers and OS vendors (yeah, they're a plague on win10/11 too)? It even makes sense to require an EV TLS cert for any push notification service. There are many ways to tackle this, but the naive way of just letting anyone set up a random site and start spamming people is so 90's/2010's. At least as a default, it should be very hard to be able to ask users to permit your push notification service.

I think part of the problem is that push notifications became a thing on mobile platforms, where apps are vetted by app stores. But random website don't undergo any vetting before they can start pushing notifications to browsers. Another issue is that people who are part of these design decisions are too far removed from regular people who don't even know what a push notification is, they just accept random prompts and get increasingly miserable over all the popups over time. It is also very easy to allow a push notification, but the UI/UX is difficult to audit/disable these. Perhaps having some button or option in the notification box to disable similar notifications would go a long way?

In a way, the web industry re-introduced the annoying pop-up windows of the early internet.

> Web Push on Apple’s platforms uses the same Apple Push Notification service that powers native push on all Apple devices. You do not need to be a member of the Apple Developer Program to use it.

This has... interesting implications for natives apps, at least at first glance.

Also, it's not clear to me how you send to a website using this. Has Apple wildly overhauled APNS server-side since I implemented a sender-client for it years and years ago? That design was excellent, but you did need a push key tied to an app to even connect to the socket IIRC. Do they issue those for websites, now? Does it work totally differently? How does validation work?

I don't get it, they pretend they made this new proposal because of security and battery life. And then we have dozens of native apps installed that push tons of useless notifications for upselling shit and clutter the screen... I had to disable all of them. So i don't understand why they fear web push so much

Declarative Web Push seems like a beneficial addition, simplifying push notification integration. The declarative approach aligns well with modern web development. However, I'm curious about the performance implications compared to the existing API and how much flexibility developers might lose with this higher-level abstraction.

I've commented this before, but does this grant an exemption from the automatic purging that ITP does? the wording makes it seem like it does but that just makes their justification for ITP all the more baffling

iOS Safari only allows push notifications for web apps added to the Home Screen, (as PWAs sometimes do), and that hasn't changed with the new Declarative Web Push. Most developers aren't familiar with this, and neither are users, and so it's very, very hard to educate users on how to allow you to push notifications.

Here's how it works.

First, users have to figure out how to add your web app to the home screen. There's no "Install" button that you can put in your web UI; users just have to know how. You can, of course, explain how, in your web page, but it's quite tricky. I'll explain it below; it takes like eight or nine steps.

First, the user has to click the Share button, the box with an arrow on it under the URL bar. On iPad, it's in the URL bar. It doesn't have the word "Share" on it, so if you use the word "Share" to describe it, users will get confused.

Also, the Share button may not be visible on the screen if the user has scrolled at all, because Safari collapses Safari's bar by default, but you can bring it back by scrolling back up to the top of the screen, or asking users to set up push notifications on a special page of your site that's too short to scroll.

Once they've clicked that, they need to find the "Add to Home Screen" button. On iPhone, "Add to Home Screen" is not visible by default either. The Share sheet is only half the height of the screen, and you have to scroll it to reveal more sharing options. One of the sharing options is "Add to Home Screen."

Once they've clicked that, they have the option to rename your app to whatever they want. You can control the default, but you can't prevent them from giving it a cute nickname, which they may forget later. Then, they can click the Add button.

When they click it, the sheet disappears. As far as the user can see, nothing useful has happened. But something has happened. There's a new app icon on their home screen. Not their first home screen, of course… it's probably their last home screen or something. There's no way for users to know which screen it's on. Or, they can search their iPhone for your app, if they can remember what it's called.

Anyway, once your web app has been added to the home screen, you have to tell your users to re-launch your app from that home-screen app launcher. It boots up slowly, slower than Safari, because it's running a whole separate process from Safari. (Also, JS in general just runs slower in home-screen web apps; only Safari is allowed to do JIT just-in-time compilation of JS.)

Finally, once they launch your app from your home screen, you can request permission to push. They have to click a button in your web UI (any click is fine), and then you can pop-up an iOS push permission request. If the user says no, you've missed your only chance; users have to go find your app in iOS Settings to turn on push.

Once users agree to push notifications in your home-screen web app, finally, finally, you can now send push notifications.

I even worked at Apple back in the day but it took me until seeing this post to realize WebKit also follows the same framework naming scheme that Apple always follows with AppKit, WatchKit, UIKit, HealthKit, GameKit, ARKit.

For some reason I didn't put WebKit into the same bucket.

Notifications have been hi-jacked by corporations allowing them to effectively push ads to your lock screen.

It’s ghetto that Apple allows it, because publishers put these ads side-by-side with actual informational notifications.

Wait, this may be a huge game changer. But only if websites no longer have to ask the user to install the app on the home screen (arcane) and then launch it, and enable notifications.

I'm sure declarative web push is great. But most of this post sounds to me like they are trying to justify artificially restricting web push notification functionality on the web and offer an inferior solution instead. It's pretty clear they (and Google, to a lesser extent) don't want web apps to be on the same level as native apps. Cynically, I believe this is so they can continue to maintain full control of the app market.

There's a lot of statements that are presented as facts, when in fact they are not.

For example:

> Therefore we require push subscriptions to set the userVisibleOnly flag to true. While this can be frustrating, the original Web Push design made this necessary to protect user privacy and battery life.

Surely this wasn't the only option to "protect user privacy and battery life". Native apps can handle push subscriptions without this sort of flag. It's frustrating because it's _meant_ to be frustrating so that users prefer native apps over web apps.

> Allowing websites to remotely wake up a device for silent background work is a privacy violation and expends energy.

This _may_ be true in some cases, but it isn't inherently true. I'm sure there are many use cases for this that are NOT a privacy violation. And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.

And again: this is perfectly OK for a native app to do. How is it really any different to allow web apps to do it? Because Apple doesn't get to review every app to their ever-changing standards?

At the end of the day this just further divides the native app from the web app, such that it's impossible for the latter to compete with the former.