The "send" part I understand. What I don't understand is the "store" part.
And is the Apple's routing even needed? Web push notification don't need Apple, Google, Microsoft or Ubuntu between the web app and you. Can't app push notifications work in the same way?
They do. To implement "web push", each web browser vendor has their own backend server to handle notification subscriptions[1][2].
- Mozilla Firefox uses their server at "push.services.mozilla.com"
- Google Chrome uses their server "fcm.googleapis.com"
- Apple Safari uses "api.push.apple.com"
- MS Edge uses their Windows Notification API server
[1] https://stackoverflow.com/questions/53169001/web-push-do-the...
[2] https://stackoverflow.com/questions/48683770/how-are-web-pus...
[3] https://news.ycombinator.com/item?id=38430226
The web push architecture requiring middleman servers in between the website and the browser is similar to native iOS apps requiring the APNS server (Apple Push Notification Server):
[4] https://stackoverflow.com/questions/17262511/how-do-ios-push...
If the device is not able to receive the notification at the time it was sent out, it has to be stored somewhere, pending delivery. It's the same with email, SMS, literally every messenger app, heck it's the same with physical parcels!
You could argue the protocol should allow the sender to store the message, to allow the receiver to fetch it directly, without a middleman - and this is more or less what RSS is, except the polling architecture causes both extra latency and increased server load. But we could "fix" RSS by eliminating polling, etc - that's an easy engineering problem, the true issue would be standards/consensus.
Finally, since we're talking mobile devices, you must consider battery usage. It's cheaper to keep only a single TCP connection open; this path is heavily optimized at every layer of the stack, from network hardware and drivers to the app-facing API. Notably, email notifications have to go through their own network path (there's a couple of IMAP extensions to enable push), this is part of the reason why some email apps would like to look at your email from the POV of their own hosted backend.
These choices reflect the fundamental problems of mobile messaging. But we could still improve upon the status quo - like requiring E2EE for notification payload. That would be a huge effort though, as an app vendor you already need to implement APNS/FCM/Web (all very different from one another), and I'm sure every middleman would like to build their encryption slightly differently. Adoption would be slow and painful.
I think the "stored?" question isn't about the minimal fraction of time notifications have to be in transient storage to even "send and immediately forget". Yes, a transitory "message queue pub/sub" architecture still needs to have some notion of "storage" to work.
Instead, "stored?" is wondering about a company's discretionary and optional retention period after the successful notification delivery that isn't required by law. E.g. 30 days?, or 1 year?, or longer? ... such that those archive records of past notifications have become targets for court subpoenas and law enforcement information requests. If Apple doesn't "store" notifications in this sense, there's nothing to "hand over".