Declarative Web Push

https://webkit.org/blog/16535/meet-declarative-web-push/

by janandonly • 1 year ago

81 70 1 year ago

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?

afavour3• 1 year ago

The way web sites register for push is very different to the way Apple requires for APNS. They're using the same service to send the pushes but the client-side interface is totally different.

holycrapwhodat3• 1 year ago

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

Note: The fact that Web Push for Apple's browsers uses APNS and doesn't require any sort of developer account is not new to Declarative Web Push. It's how it's always been since Web Push first shipped in Safari 13 on macOS - https://developer.apple.com/documentation/usernotifications/...

ftbsqcfjm• 1 year ago

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.

om26• 1 year ago

It reduces notification display latency because they can be displayed directly by the system services managing push, without having to wait for an opportune time to fire up a service worker process. It does still allow customizing the notification with code, but even in that case, having the declarative notification as a fallback improves reliability.

therein• 1 year ago

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.

robertoandred• 1 year ago

The "Kit" nomenclature dates back to the NeXTSTEP days.

dfabulich• 1 year ago

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.

hackernudes2• 1 year ago

I just want to say I appreciate your rant. Maybe this declarative web push API signals they are spending some developer time improving the "Add to Home Screen" experience overall.

I hope the whole industry pushes to prefer websites-as-apps. So many services have both native apps and websites and one or the other is broken or limited for no good reason other than it's hard to develop two things instead of one.

miramba• 1 year ago

Just a workaround, but someone made a helping pop-up: https://github.com/ryxxn/pwa-install-prompt

Last time I checked, push messages did not work when the web app was not running, has that changed? Because I think that is the most interesting feature for users: To notify about important things while not using the app. It has also always been abused by app creators with useless stuff to drive engagement etc. I think I never allowed a single webpage to send me notifications - if for example I want to know about the latest news about plant pottery, I will probably just visit that website again...no need to notify me.

littlecranky675• 1 year ago

Push notifications work anytime, even when your phone is locked and in your pocket. On iOS you need to add the website "to your home screen", which then it becomes like an App (it is a progressive web app, PWA). For Chrome and Safari on Desktop it is the same (you even get notifications when your laptop is locked on macOS, provided you configured that in your settings of macOS).

Source: I run a PWA that enables web push (without any 3rd party push services) and have tested it many times on many platforms, and my users use them too.

madeofpalk2• 1 year ago

Good.

I hate it when random websites on desktop ask to send notifications. I'm so glad randomly browsing on the web doesn't trigger this on mobile.

EGreg4• 1 year ago

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.

MBCook3• 1 year ago

It says they still do. And I’m glad about that.

EGreg4• 1 year ago

I'm definitely not glad about it.

They are doing it to make sure their apps still have an edge over websites.

alana314• 1 year ago

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.

kemayo• 1 year ago

Apple's approach of only allowing sites that you've pulled out onto your home screen to request them is actually not bad for balancing this. It means I'm not being constantly nagged while browsing normally, but when I decide I want to treat something "like an app" it gets access to richer features.

(I very rarely do this. I think the only thing I have pulled out like that currently is Puzzmo, which doesn't even do notifications.)

Rohansi2• 1 year ago

It's a decent way to handle permission but it's never "like an app" with iOS. Web push is missing basic features on iOS, such as notification sound/vibration. Many will say that's a good thing but there is no restriction for actual apps. I would love to rewrite a React Native app I work on as a PWA but silent notifications are totally useless for it.

cosmic_cheese2• 1 year ago

There are some legitimate use cases for them, but generally I think web push permissions are best defaulted to “no” so sites can’t harass users with fake, “we need to maintain the ability to harass the users again” in app prompts.

madeofpalk2• 1 year ago

Every request for notification permission is best defaulted to No. It shocks me how eager people are to opt-into getting spam and other junk alerting on their phone.

shiomiru• 1 year ago

Among less technologically literate acquaintances, getting a gazillion browser notifications on startup seems to be the modern equivalent of accidentally installing tons of useless toolbars.

Jaxan• 1 year ago

Another thing that drives me nuts is the choice “yes / yes always / ask again next time”. I want “no never”!

tyushk• 1 year ago

How will they ever get you to accidentally click "yes" if it doesn't pop up again?

l72• 1 year ago

My company has a product that allows you to chat with tech support. The end user (our customer's customer), is just someone who went to one of our customers' help portals and requested help via chat.

These chats are going to last < 1 hour typically. There are times when the custom support agent needs to confer with someone else, and then will respond back. The end user, in that case, does not want to sit there with their phone open for 15 minutes, waiting for a response.

While we have an app those end users could download and get notifications on, no one wants to do that for a one off session (not even an App Clip).

Trying to get iOS users to add it to their home screen, is basically a no-go too.

So, it would be really nice if we had a way to send push notifications, even if it was time limited (allow notifications for the next 1 hour).

Don't get me wrong, Push Notification can and are abused. But there are valid use cases.

postalrat• 1 year ago

A rational person would avoid websites that flood with you things you don't want.

yencabulator• 1 year ago

I currently have a browser tab open somewhere that is beeping and probably changing its title text, and I have no clue which tab it is. I for sure would prefer having a way to ask my browser for a list of recent notifications and the tabs involved, regardless of whether they deserved a pop-up window on my screen or not.

hackernudes2• 1 year ago

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?

littlecranky675• 1 year ago

Is there something similar like this on Android?

It works out of the box on Android (without adding to the homescreen or installing as PWA). For iOS, you need to tap the "share" button in safari, scroll down, and "Add to homescreen".

If you want to test this out (on either platform), you can try my PWA where I implemented this (https://lockmeout.online). In the users settings, you can even add several devices (browser, phones etc.) and send a test notifications to either a single or all devices. Installation instructions for iOS and Android are there (since it is a PWA, you just need to press the right buttons in the browser, there is not actual installation). PWAs can also be installed on Desktop (Chrome and Safari).

Btw. the PushNotification API is not device/vendor specific. I use the same code to send out notifications for mobile (iOS, Chrome Android) and Desktop (safari, firefox, chrome etc.). I also do not use any third party for sending, but do it from my server. And hell yeah, not having to create these clumsy serviceworkers will simplify my code a lot.

callahad• 1 year ago

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.

In the case of Apple's ecosystem, the device maintains a connection to the Apple Push Notification service (APNs). The website POSTs notifications to APNs, which forwards them on to the user's device. The user's device then wakes up a local Service Worker for that website in order to process the incoming payload and display a notification.

Declarative Web Push makes the very last step unnecessary.

(It's the same on Android but using Firebase Cloud Messaging instead of APNs. Mozilla also runs a push service and its source is at https://github.com/mozilla-services/autopush-rs/)

joekrill5• 1 year ago

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.

afavour3• 1 year ago

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.

Ironically the reality here is backwards: for a very long time iOS apps could _only_ send declarative push alerts. Only since iOS 10 were you able to use a UNNotificationServiceExtension to customize the content on-device. That extension has very strict resource and CPU limits and is terminated if it violates them. Even when you do have this extension you still need to send a declarative payload in case the on-client code fails, exactly the same as Declarative Web Push requires.

And running _any_ amount of code "expends energy", so it seems silly to even imply that is a problem.

There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON. In fact, worker boot up speed is a recognized problem to the extent that there's an entire API to handle situations where a network response would load quicker than a Service Worker might:

https://developer.mozilla.org/en-US/docs/Web/API/NavigationP...

Years ago I actually tried spinning up a JSContext in a notification extension out of curiosity and the extension was immediately killed for exceeding resource limits. May well not be the case today but the logic still makes sense to me.

Apple is no saint and has done plenty of negative things for web apps. But in this specific instance they're making the right call, IMO: requiring backup notification content for when client-side code fails is sensible.

joekrill5• 1 year ago

Ironically the reality here is backwards:

Maybe you quoted the wrong the thing? but there's no irony here, and it's definitely not backwards in reality: Apple and Google have both severely limited what PWAs can do such that they are vastly inferior to native apps. It would very difficult to argue otherwise.

There's a big difference between running some native code and spinning up an entire JS virtual machine and worker environment to (effectively) modify some JSON

Presumably React Native apps do something to that extent? Or, if they don't, whatever optimization they use could certainly be applied "under-the-hood" to PWAs.

cosmic_cheese2• 1 year ago

The big difference, as always with web apps, is intent and consent.

Installing an app is a strong signal that the user actually wants/needs it. The level of consent is much higher right out of the gate. With web apps on the other hand, the user can be swept away by a redirect, accidental tap, maliciously captured tap (think a transparent element covering the whole page), etc. There’s a much higher chance that users never intended to end up where they’re at and don’t actually want anything from the app.

Following this train of thought, it stands to reason to have a looser policy with apps. If there’s a way to install web apps with the same level of consent (PWA listings in an App Store for example), standards could be loosened when users come through that route, but for navigating to any random web address things should be more tight.

joekrill5• 1 year ago

The user already has to explicitly "install" a PWA on iOS. See dfabulich's comment in this same thread for how overly complicated and convoluted that process is currently. So there's a pretty good argument that installing a PWA actually require much, much MORE intent than a native app from the app store.

Similarly, the user needs to consent to notifications (among other things) just as they do for native apps.

aeontech2• 1 year ago

Mozilla seems to be in favor as well: https://github.com/mozilla/standards-positions/pull/1190 (and funnily enough, a comment on this PR agrees with you in that background work might not be a significant factor in terms of energy consumption, but they still think this is a better design than the original Web Push spec).

Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:

Activating a service worker to deliver a push message can result in increased resource usage, particularly of the battery. Different browsers have different schemes for handling this, there is currently no standard mechanism. Firefox allows a limited number (quota) of push messages to be sent to an application, although Push messages that generate notifications are exempt from this limit. The limit is refreshed each time the site is visited. In Chrome there are no limits.

[0] https://developer.mozilla.org/en-US/docs/Web/API/Push_API

Anyway, let's put a defensive hat on for a moment, and assume we're dealing with malicious actors (and OF COURSE we're going to be dealing with malicious actors, this is the internet, come on).

Surely this wasn't the only option to "protect user privacy and battery life".

First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.

Native apps can handle push subscriptions without this sort of flag.

Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work with.

If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).

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

I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.

In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?

But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)

joekrill5• 1 year ago

Also, interestingly, in the original Web Push spec, they did think that energy consumption was enough of a concern that they implemented a quota system:

I never suggested energy consumption wasn't a concern. I said any code that runs expends energy. So to pretend it's a concern only for PWAs is silly. It's a concern for both web and native apps alike. But (as I understand from other comments) native apps get some sort of quota on iOS, while web apps don't even get that option.

First off, I notice you are confident that this wasn't the only option (there's never only one option, so the statement as it stands can't be falsified), but you don't actually _provide_ any alternative ideas.

I didn't suggest an alternative because: 1) the post says it was "necessary" implying there was no other option: "the original Web Push design made this necessary to protect user privacy and battery life." But more importantly: 2) they don't go into what those privacy options _are_, exactly. So it's not really possible to address this broadly-defined privacy issue. Maybe it's buried in a Github discussion somewhere, but it's certainly not addressed in this blog post - they just say there's a privacy issue, and that's that.

Native apps require a push token to send notifications, which can be revoked. If/when a native app abuses the user trust, it's easy to also ban the entire app, or ban the entire developer account in the worst case scenario. Even that often doesn't stop bad actors, but it does give some tools to the defenders to work

This isn't any different for web. Web app push notifications also require a token that can be revoked. The article even says "if an event handler doesn’t show the user visible notification for any reason we revoke its push subscription". So they do this already.

If I am running an abusive web app, I can spin up two dozen clones before breakfast when a particular domain gets blacklisted, and there is no way to ban me (that I know of).

So associate push notifications with a specific account in some way, similarly to how native apps work.

I'd love to see a heuristic that can be automatically applied to an incoming push notification to determine whether or not it's going to cause a privacy violation or excessive energy use.

I can't speak to the vague idea of what a "privacy violation" is without understanding what the specific concern is. Is it geolocation? IP address? Fingerprinting? Regardless, iOS already uses a heuristic for native apps, so why can't a similar heuristic be used for web apps?

In fact, maybe we can use the same heuristic with my geolocation API - after all, while some requests to the API _may_ be malicious, most of them aren't - surely there is no need to add safety guardrails that make malicious requests impossible or at least more difficult - we could just tell the computer to recognize and ignore evil requests, and only allow the good requests, right?

That's quite the straw man, considering Service Workers can't even access the geolocation API. But also, the geolocation API requires explicit user consent. But I'll ask again (and this is really my main beef with all this): why is this totally fine for native apps but not for web apps?

But, maybe you're right, and none of these are concerns to worry about - the main reason is to just make developer's life harder (though in that case, wouldn't the easiest solution be not to bother implementing any of this API at all?)

I don't think it's "just make developer's life harder". My personal opinion - as I mentioned previous - is that it's because Apple (and Google, to a lesser extent) want to maintain as much control over the mobile app market as possible. All payments go through them. They can shut down any app (ahem, competition) they please for any number of vague reasons. If web apps can be built with the same capabilities as native apps they won't be able to maintain that monopoly.

butz• 1 year ago

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

andrewmcwatters• 1 year ago

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.

littlecranky675• 1 year ago

Apple only allows it when you add the website to your home screen (a.k.a Install progressive web app). A user only does this when they are actually interested in the site. Once added to the home screen, it is like any other app, and you can manage the notifications from that app via iOS Settings.

fidotron2• 1 year ago

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.

littlecranky675• 1 year ago

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

Can you elaborate? I runa PWA on my iPhone and once the PWA is installed ("added to home screen") you can manage the notification display (grouping, lockscreen, temporary/persistent) just as with any other app installed via the iPhone Settings -> Notifications.

Replacing previous notifications is not possible in the web-push standard at all, so it is not apple to blame.

fidotron2• 1 year ago

It totally is: https://developer.mozilla.org/en-US/docs/Web/API/Notificatio...

"The idea of notification tags is that more than one notification can share the same tag, linking them together. One notification can then be programmatically replaced with another to avoid the users' screen being filled up with a huge number of similar notifications."

Apple are the only ones not supporting this, and much of the time with web stuff they have a point, but this one just seems obtuse.

om26• 1 year ago

In Safari 18.4 (currently in beta) tags are supported and notifications can replace each other.

notepad0x902• 1 year ago

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.

daveoc64• 1 year ago

Why are such technologies still possible, even after we've learned lessons from email and other legacy tech over the past several decades?

The alternative seems far more disappointing from an engineering and architecture perspective to me - not bothering to implement any features because of fears that they may be abused.

notepad0x902• 1 year ago

I'm doubly disappointed because of your comment because that is not the alternative. You implement the technology with user experience as #1 priority and build layers upon layers of defenses against abuse and with trust establishment as its foundation.

hollowturtle3• 1 year ago

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

jchw• 1 year ago

I always disable push notifications for the very first push notification I receive that is an advertisement regardless of service. And what's crazy is, basically everyone does it now. Amazon does it, even, and I don't think there's an obvious way to just disable ads. Fine, fuck you, I'll just use e-mail, then.

om26• 1 year ago

iOS and macOS native app notifications already work the way Declarative Web Push does, not like classic Web Push. This is giving web apps the same ability to be battery friendly and more reliable that native apps already have.

hollowturtle3• 1 year ago

again battery friendly how? because you install them first? please... as I said native apps still abuse notification system(and battery) pushing ads. Apple just hate the web platform, and them trying to push alternative solutions is just PR for how little they care about PWAs and their progression

mary-ext• 1 year ago

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

holycrapwhodat3• 1 year ago

Since there is no service worker required, if ITP removes the service worker, declarative web push continues to work. I believe this is explicitly called out.

Declarative Web Push

Related Stories