7 ms·

Declarative Web Push

81 points by janandonly 2y ago

alabastervlog 2y 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?
- afavour 2y 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.
- holycrapwhodat 2y 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/sending-web-push-notifications-in-web-apps-and-browsers https://developer.apple.com/documentation/usernotifications/...
ftbsqcfjm 2y ago
[dead]
- om2 2y 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 2y 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 2y ago
  The "Kit" nomenclature dates back to the NeXTSTEP days.
dfabulich 2y 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.
EGreg 2y 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.
- MBCook 2y ago
  It says they still do. And I’m glad about that.
  - EGreg 2y ago
    I'm definitely not glad about it. They are doing it to make sure their apps still have an edge over websites.
    - MBCook 2y ago
      I know that’s a popular sentiment here, but I honestly don’t think they give a shit. This is 100% understandable to me as something to prevent random unknown websites from sending push notifications users don’t expect or know how to control from a site they accidentally visited weeks ago.
      - EGreg 2y ago
        Accidentally visiting a website doesn’t give it permission to send notifications. Seriously, it is not that difficult to let users choose whether to receive notifications, how often, and manage them later. Apple just had negative incentive to do that on the Web!
        MBCook 2y ago
        They have to agree to a pop-up. Guess what, people do that all the time. They get tricked into it. They just press a button really fast to get it to go away. They don’t remember doing it but then later that day or a week from then or whenever they might start getting notifications. And of course they’re incentivized to get you to go back to their website with any notification they want to show. That way they can get more views, or try to run a scam on you if it was a scam website. We already have ways of doing notifications from arbitrary third parties. It’s called email. Or you can make an app. Or you can get someone to add your site to their home screen. All are extremely clear measures of consent. At work I’m not allowed to run an ad blocker. I get stupid little pop-ups asking me if I want to enable notifications on websites all the time. As far as I’m concerned it’s all spam. I LIKE Apple’s stance. I LIKE they’re preventing me from having to see a stupid little permissions dialogue on every new website I go to asking me if I want to enable notifications.
alana314 2y 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 2y 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.)
  - Rohansi 2y 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.
    - om2 2y ago
      Web Push does have the sound option now.
- cosmic_cheese 2y 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.
  - madeofpalk 2y 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.
hackernudes 2y 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?
- littlecranky67 2y 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 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 2y 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/ https://github.com/mozilla-services/autopush-rs/)
joekrill 2y 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.
- afavour 2y 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/NavigationPreloadManager 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.
butz 2y ago
Still waiting for Alarms API to be implemented in web browsers to finally build my "Reminders" web app.
andrewmcwatters 2y 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.
- littlecranky67 2y 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.
  - deleted 2y ago
    [deleted]
fidotron 2y 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.
- littlecranky67 2y 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.
  - fidotron 2y ago
    It totally is: https://developer.mozilla.org/en-US/docs/Web/API/Notification/tag 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.
    - littlecranky67 2y ago
      You are right, wasn't aware of it. Looks like Chrome didn't implement this either. I'm not an android user, but to be fair, there is no way Notifications can be grouped like this on iOS with native apps.
notepad0x90 2y 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 2y 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.
  - notepad0x90 2y 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.
hollowturtle 2y 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 2y 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.
- om2 2y 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.
  - hollowturtle 2y 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
    - panic 2y ago
      This is a PWA-only feature; why would they spend the time to implement this if they didn’t care about PWAs?
      - hollowturtle 2y ago
        also a webkit only feature far from the web standard, hence their carelessness
mary-ext 2y 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
- holycrapwhodat 2y 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.

81 points by janandonly 2y 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?

afavour 2y 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.
holycrapwhodat 2y 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/sending-web-push-notifications-in-web-apps-and-browsers https://developer.apple.com/documentation/usernotifications/...

ftbsqcfjm 2y ago

[dead]

om2 2y 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 2y 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 2y ago
The "Kit" nomenclature dates back to the NeXTSTEP days.

dfabulich 2y 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.

EGreg 2y 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.

MBCook 2y ago
It says they still do. And I’m glad about that.
- EGreg 2y ago
  I'm definitely not glad about it. They are doing it to make sure their apps still have an edge over websites.
  - MBCook 2y ago
    I know that’s a popular sentiment here, but I honestly don’t think they give a shit. This is 100% understandable to me as something to prevent random unknown websites from sending push notifications users don’t expect or know how to control from a site they accidentally visited weeks ago.
    - EGreg 2y ago
      Accidentally visiting a website doesn’t give it permission to send notifications. Seriously, it is not that difficult to let users choose whether to receive notifications, how often, and manage them later. Apple just had negative incentive to do that on the Web!
      - MBCook 2y ago
        They have to agree to a pop-up. Guess what, people do that all the time. They get tricked into it. They just press a button really fast to get it to go away. They don’t remember doing it but then later that day or a week from then or whenever they might start getting notifications. And of course they’re incentivized to get you to go back to their website with any notification they want to show. That way they can get more views, or try to run a scam on you if it was a scam website. We already have ways of doing notifications from arbitrary third parties. It’s called email. Or you can make an app. Or you can get someone to add your site to their home screen. All are extremely clear measures of consent. At work I’m not allowed to run an ad blocker. I get stupid little pop-ups asking me if I want to enable notifications on websites all the time. As far as I’m concerned it’s all spam. I LIKE Apple’s stance. I LIKE they’re preventing me from having to see a stupid little permissions dialogue on every new website I go to asking me if I want to enable notifications.

alana314 2y 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 2y 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.)
- Rohansi 2y 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.
  - om2 2y ago
    Web Push does have the sound option now.
cosmic_cheese 2y 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.
- madeofpalk 2y 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.

hackernudes 2y 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?

littlecranky67 2y 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 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 2y 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/ https://github.com/mozilla-services/autopush-rs/)

joekrill 2y 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.

afavour 2y 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/NavigationPreloadManager 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.

butz 2y ago

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

andrewmcwatters 2y 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.

littlecranky67 2y 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.
- deleted 2y ago
  [deleted]

fidotron 2y 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.

littlecranky67 2y 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.
- fidotron 2y ago
  It totally is: https://developer.mozilla.org/en-US/docs/Web/API/Notification/tag 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.
  - littlecranky67 2y ago
    You are right, wasn't aware of it. Looks like Chrome didn't implement this either. I'm not an android user, but to be fair, there is no way Notifications can be grouped like this on iOS with native apps.

notepad0x90 2y 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 2y 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.
- notepad0x90 2y 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.

hollowturtle 2y 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 2y 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.
om2 2y 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.
- hollowturtle 2y 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
  - panic 2y ago
    This is a PWA-only feature; why would they spend the time to implement this if they didn’t care about PWAs?
    - hollowturtle 2y ago
      also a webkit only feature far from the web standard, hence their carelessness

mary-ext 2y 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

holycrapwhodat 2y 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.