[HN Gopher] Declarative Web Push
___________________________________________________________________
Declarative Web Push
Author : janandonly
Score : 68 points
Date : 2025-03-31 12:06 UTC (3 days ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| alabastervlog wrote:
| > 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 wrote:
| 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.
| ftbsqcfjm wrote:
| 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.
| therein wrote:
| 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 wrote:
| The "Kit" nomenclature dates back to the NeXTSTEP days.
| dfabulich wrote:
| 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.
| hackernudes wrote:
| 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 wrote:
| 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.
| littlecranky67 wrote:
| 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.
| madeofpalk wrote:
| 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.
| EGreg wrote:
| 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 wrote:
| It says they still do. And I'm glad about that.
| EGreg wrote:
| I'm definitely not glad about it.
|
| They are doing it to make sure their apps still have an edge
| over websites.
| MBCook wrote:
| 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 wrote:
| 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!
| alana314 wrote:
| 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 wrote:
| 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.)
| cosmic_cheese wrote:
| 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 wrote:
| _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 wrote:
| 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 wrote:
| Another thing that drives me nuts is the choice "yes / yes
| always / ask again next time". I want "no never"!
| tyushk wrote:
| How will they ever get you to accidentally click "yes" if it
| doesn't pop up again?
| l72 wrote:
| 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 wrote:
| A rational person would avoid websites that flood with you
| things you don't want.
| hackernudes wrote:
| 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 wrote:
| > 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 wrote:
| > _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/)
| joekrill wrote:
| 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 wrote:
| > 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.
| joekrill wrote:
| > 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.
| afavour wrote:
| > Presumably React Native apps do something to that extent?
|
| Not in the background they don't, no.
|
| > Or, if they don't, whatever optimization they use
|
| They don't have one. There is no optimization they can do
| to run JS in the background. Push notifications in a React
| Native app either use native code or rely on declarative
| payloads sent from the server.
| cosmic_cheese wrote:
| 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.
| joekrill wrote:
| 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.
| aeontech wrote:
| 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?)
| butz wrote:
| Still waiting for Alarms API to be implemented in web browsers to
| finally build my "Reminders" web app.
| andrewmcwatters wrote:
| 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 wrote:
| 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.
| fidotron wrote:
| 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 wrote:
| > 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 wrote:
| 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.
| littlecranky67 wrote:
| 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.
| threeseed wrote:
| Apple groups notifications using on their on-device AI.
|
| So even if it was supported the OS would just ignore it.
| notepad0x90 wrote:
| 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 wrote:
| >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.
| mirkodrummer wrote:
| 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 wrote:
| 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 wrote:
| 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.
| mirkodrummer wrote:
| 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 wrote:
| This is a PWA-only feature; why would they spend the time
| to implement this if they didn't care about PWAs?
| mirkodrummer wrote:
| also a webkit only feature far from the web standard,
| hence their carelessness
| threeseed wrote:
| I expect you will apply this to the other browsers who
| are 100x worse than Apple at adding proprietary features.
|
| And if you read the article Apple reached out to the
| other browser vendors to push it as a standard.
___________________________________________________________________
(page generated 2025-04-03 23:02 UTC)