Web Push for Web Apps on iOS and iPadOS(webkit.org)
webkit.org
Web Push for Web Apps on iOS and iPadOS
https://webkit.org/blog/13878/web-push-for-web-apps-on-ios-and-ipados/
378 comments
An important detail that you might miss without reading the article is that these capabilities are not available to any website a user visits. The user must add the website to the their Home Screen before the website can ask for notifications permissions.
As an iOS user I actually like this restriction. Can't imagine what the browsing experience would've looked like if any website could take their chance on sending me notifications
As an iOS user I actually like this restriction. Can't imagine what the browsing experience would've looked like if any website could take their chance on sending me notifications
> Added support for WASM SIMD.
This is huge for the progress of WASM
> Added support for growable SharedArrayBuffer.
Not a headliner feature, but a pretty important one for JS/WASM interactions.
> Added support for AVIF on macOS Monterey and macOS Big Sur.
> Added support for the AV1 codec in the MediaCapabilities API.
> Added WebRTC support for hardware AV1 decoding on supported device configurations.
Could this be the first indication of Apple warming to AV1?
> Added support for the Notification API in dedicated workers.
> Added support for Service Workers and Shared Workers to the Permissions API.
> Added support for the termination of nested workers.
Nice to see web workers finally getting some love
> Added support for CSS Typed OM.
A great feature and should help with performance from not having to do constant number->string->number
This is huge for the progress of WASM
> Added support for growable SharedArrayBuffer.
Not a headliner feature, but a pretty important one for JS/WASM interactions.
> Added support for AVIF on macOS Monterey and macOS Big Sur.
> Added support for the AV1 codec in the MediaCapabilities API.
> Added WebRTC support for hardware AV1 decoding on supported device configurations.
Could this be the first indication of Apple warming to AV1?
> Added support for the Notification API in dedicated workers.
> Added support for Service Workers and Shared Workers to the Permissions API.
> Added support for the termination of nested workers.
Nice to see web workers finally getting some love
> Added support for CSS Typed OM.
A great feature and should help with performance from not having to do constant number->string->number
I'm already dumbfounded by the number of notifications I see pop up on relative's screens, this can only add to it. My default is to not allow notifications unless the application has a very good reason for needing it, and even then if they abuse that the notifications get turned back off.
It's one of many moves Apple is making in what I'm assuming is to assuage antitrust concerns. I think it's an overall good because having choice is good, but I do suspect I'll start seeing even more spam on people's notifications as a result.
It's one of many moves Apple is making in what I'm assuming is to assuage antitrust concerns. I think it's an overall good because having choice is good, but I do suspect I'll start seeing even more spam on people's notifications as a result.
Oh hey, bullying companies with threats of antitrust works. We should do that more often.
----
This is a really big deal, but it's also a little bittersweet, because Push Notifications very heavily motivate developers to introduce serverside components to apps that don't need them. Web Push is a standard where I can really see Google's influence, and I think it influenced the standard for the worse. It's a standard built around the way that Google and large companies build products, it's not built around indie development or hobby projects.
You can send a notification to whatever server is registered and it gets delivered to the phone, great. In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.
And yes, sometimes you do need a serverside connection for things like message notifications, but there are a lot of uses for notifications where you know upfront what the notification needs to say and when it needs to be shown -- and that's not supported. In my opinion because Google doesn't really think about that kind of architecture and the idea that you wouldn't contact a server alongside every user action is foreign to them.
There was effort for a while to get offline alarms, scheduled notifications, even scheduled actions working through web workers, but as far as I know that stuff has all died off. It stinks, because I regularly run into scenarios where I could probably flat-out replace an app on my phone with a website, and I can't even on Android, because I'm unwilling to set up an account system and start tracking a bunch of data. I'm happy we have something, but I'm still remembering the parallel world we lost, where it would have been possible to have a much broader push towards completely offline PWAs that never transmitted user data anywhere. The idea of being able to replace native apps with a static Netlify page is very appealing to me.
And maybe that'll change? But I'm not holding my breath; it seems like a lot of companies have decided that push notifications are good enough and that they were going to require user accounts anyway.
----
This is a really big deal, but it's also a little bittersweet, because Push Notifications very heavily motivate developers to introduce serverside components to apps that don't need them. Web Push is a standard where I can really see Google's influence, and I think it influenced the standard for the worse. It's a standard built around the way that Google and large companies build products, it's not built around indie development or hobby projects.
You can send a notification to whatever server is registered and it gets delivered to the phone, great. In contrast, there is no way for a PWA (unless something has changed since I last looked, in which case PLEASE tell me) to schedule a notification for the future without contacting a server. It's a bad direction to go for PWAs, given that the whole point is for them to be able to work offline.
And yes, sometimes you do need a serverside connection for things like message notifications, but there are a lot of uses for notifications where you know upfront what the notification needs to say and when it needs to be shown -- and that's not supported. In my opinion because Google doesn't really think about that kind of architecture and the idea that you wouldn't contact a server alongside every user action is foreign to them.
There was effort for a while to get offline alarms, scheduled notifications, even scheduled actions working through web workers, but as far as I know that stuff has all died off. It stinks, because I regularly run into scenarios where I could probably flat-out replace an app on my phone with a website, and I can't even on Android, because I'm unwilling to set up an account system and start tracking a bunch of data. I'm happy we have something, but I'm still remembering the parallel world we lost, where it would have been possible to have a much broader push towards completely offline PWAs that never transmitted user data anywhere. The idea of being able to replace native apps with a static Netlify page is very appealing to me.
And maybe that'll change? But I'm not holding my breath; it seems like a lot of companies have decided that push notifications are good enough and that they were going to require user accounts anyway.
Web Push is probably the worst feature ever introduced to the web. I see way too many spammy notififications on PC's of my non-technical friends and parents. Glad that Apple has decided to only allow Web Push for websites added to the home screen.
Web push, badging, saving to the home screen from other browsers, and lots more.
I can’t wait to hear 6 months from now how the goalposts have moved again and some other feature no one ever complained about is now what Apple is using to destroy PWAs that would be ultra-popular if Apple would just add support.
It happens every time.
I can’t wait to hear 6 months from now how the goalposts have moved again and some other feature no one ever complained about is now what Apple is using to destroy PWAs that would be ultra-popular if Apple would just add support.
It happens every time.
Dreams do come true (https://news.ycombinator.com/item?id=22687913). Even more:
> You do not need to be a member of the Apple Developer Program to use it.
Wow.
> You do not need to be a member of the Apple Developer Program to use it.
Wow.
I'm pleasantly surprised by this news. I never thought Apple would do this and have been quite critical of them over the years due to it. For years they've really been holding up progress with PWA. I think a majority of the apps we see are really just glorified wrappers around websites anyway, or not needing more resources/tech than a website would, except bloated up to 100megs for each app because we can't just use the web browser already installed and all of the time and money wasted getting it into the app store when it should be just freely accessible via the web.
A personal gripe with progressive web apps: they cache the website!!
A lot of people have requested that I make a progressive web app for https://plaintextsports.com. I've looked into it, but it fundamentally doesn't work, because it caches the home page. My website doesn't load any data via JavaScript; it just relies on the HTML page updating every 30 seconds, so when the home page is cached, the website just stops working.
I don't want this service worker nonsense. In most cases offline access isn't useful; people want the live scores. (It'd be moderately useful for viewing schedules offline, but I think most people use it for live scores.) I just want the website to show up as its own app in the app switcher, and basically nothing else to change: I still want the swipe-to-go-back gesture to still work. I still want the address bar with the manual refresh button. But I can't do that.
It's frustrating that they've provided a way to make a certain style of websites into first-class apps, but it doesn't work for the most basic websites!!
Side note: this is partially a the-best-way-to-get-a-question-answered-on-the-internet-is-to-say-something-wrong post. If there's a way to make it a PWA and not have all the pages heavily cached, please let me know! I would love to be wrong on this. (Unfortunately my noprocast just triggered though, so I won't be able to edit this post or respond for the next three hours.)
A lot of people have requested that I make a progressive web app for https://plaintextsports.com. I've looked into it, but it fundamentally doesn't work, because it caches the home page. My website doesn't load any data via JavaScript; it just relies on the HTML page updating every 30 seconds, so when the home page is cached, the website just stops working.
I don't want this service worker nonsense. In most cases offline access isn't useful; people want the live scores. (It'd be moderately useful for viewing schedules offline, but I think most people use it for live scores.) I just want the website to show up as its own app in the app switcher, and basically nothing else to change: I still want the swipe-to-go-back gesture to still work. I still want the address bar with the manual refresh button. But I can't do that.
It's frustrating that they've provided a way to make a certain style of websites into first-class apps, but it doesn't work for the most basic websites!!
Side note: this is partially a the-best-way-to-get-a-question-answered-on-the-internet-is-to-say-something-wrong post. If there's a way to make it a PWA and not have all the pages heavily cached, please let me know! I would love to be wrong on this. (Unfortunately my noprocast just triggered though, so I won't be able to edit this post or respond for the next three hours.)
I think this is a good development. I'd rather my "app" be chunk of wasm running in a browser window then have to deal with all the drama that comes with dealing with the various app stores. Its not a universal solution but it would work for a lot of apps. Most of the non-game apps seem to be just a web widget anyway.
I can't believe they've finally added this. Been waiting at least 8 years.
This is a tremendous announcement. Web Push is such a superior channel to SMS and Email for many websites" There's a standard opt-in and opt-out process, it's real-time, and it's free. Yet the adoption has been severely reduced by the lack of iOS support.
The homescreen requirement is a small hurdle in the grand scheme of things. Now websites can finally implement Web Push once, and know that it will work for all of their users.
This is especially useful for media sites and others that have historically struggled to get people to go through the whole app store to app install process. It will level the playing field and create much better user experiences.
The homescreen requirement is a small hurdle in the grand scheme of things. Now websites can finally implement Web Push once, and know that it will work for all of their users.
This is especially useful for media sites and others that have historically struggled to get people to go through the whole app store to app install process. It will level the playing field and create much better user experiences.
There’s a huge caveat here: it only works for webapps you’ve installed to your Home Screen, which is a Byzantine process few work out organically.
It’s progress, I’m happy to see it, but Apple are still behind the curve here. It should be much, much simpler to install an app to the Home Screen when huge features like this are locked behind the gate.
It’s progress, I’m happy to see it, but Apple are still behind the curve here. It should be much, much simpler to install an app to the Home Screen when huge features like this are locked behind the gate.
Digression: The language in this post seems to straddle the line between an official Apple Press release and an open source project update. While it mentions new features added to WebKit, it also references new iOS APIs. Additionally, the term "third-party browsers" is used, even though on iOS all those browsers are simply using WebKit. From the perspective of the WebKit project, I don't view these browsers as "third-party" as they too are utilizing WebKit. Not really complaining, just something I noticed.
This is really great news for the Lightning network, if that is your thing. There is a Lightning wallet, called Mutiny Wallet (https://mutinywallet.com) which is an entirely web-based Lightning wallet/node (using WebAssembly, etc) under development. A Lightning wallet PWA is a great boost to censorship resistance because no one can be cut off from their money because of oppressive government or App Store policy.
One of the challenges of Lightning usability on mobile wallets is sending payments when there is no guarantee that the user's mobile wallet is getting the CPU time necessary to receive the payment without having the app directly open. Allowing push notification for PWA is a potential way to make sure that a user's wallet gets some CPU time for incoming payments!
One of the challenges of Lightning usability on mobile wallets is sending payments when there is no guarantee that the user's mobile wallet is getting the CPU time necessary to receive the payment without having the app directly open. Allowing push notification for PWA is a potential way to make sure that a user's wallet gets some CPU time for incoming payments!
It's good to see this happen. It'll improve the perception of Safari for developers.
It always was always treated pretty unfairly. It's easier to parrot 'Safari is the new IE' rather than consider cross compatibility when you're writing websites.
It always was always treated pretty unfairly. It's easier to parrot 'Safari is the new IE' rather than consider cross compatibility when you're writing websites.
This is much appreciated, but it also comes at an interesting time, given that true alternative browsers on iOS are probably only a few months away at this point.
That said, I wonder if alternative browsers will actually get access to the "add to homescreen" API?
That said, I wonder if alternative browsers will actually get access to the "add to homescreen" API?
A bit off topic, but worth a shot: I'm working on a rather simple web-based game and I'm struggling with how to test it for iOS/Safari/Webkit without having to go out and buy an Apple device?
> Just be sure to allow URLs from *.push.apple.com if you are in control of your server push endpoints.
Wait, why would anyone be doing any sort of whitelisting? That seems a disastrously bad idea that utterly ruins interoperability. I could understand checking that the IP address the URL resolves to isn’t private, but what they’ve written suggests something much broader.
Am I missing something, or have they gone off the deep end, or are they reacting to implementers that have gone off the deep end?
Wait, why would anyone be doing any sort of whitelisting? That seems a disastrously bad idea that utterly ruins interoperability. I could understand checking that the IP address the URL resolves to isn’t private, but what they’ve written suggests something much broader.
Am I missing something, or have they gone off the deep end, or are they reacting to implementers that have gone off the deep end?
Are these WebKit improvement driven by the EU regs? Isn't that why iOS will soon allow an alternate rendering engine? So, now WebKit finally has to keep up?
It's great to see additional capabilities being added to Safari on iOS; the bottom of the article also mentions additions of the Screen Lock, Screen Orientation, User Activation and Web Codecs APIs.
The idea of limiting some APIs to apps added to the Home Screen makes sense; I hope in the future web apps can use other features such as the Vibration, Bluetooth, Screen Capture, NFC, and Share Target APIs.
The idea of limiting some APIs to apps added to the Home Screen makes sense; I hope in the future web apps can use other features such as the Vibration, Bluetooth, Screen Capture, NFC, and Share Target APIs.
This starts very defensively, pretty clearly hitting back at the idea that iOS has been intentionally holding back the web.
For a lot of apps this would enable foregoing React Native entirely, since Push Notifications was the only must-have native feature for a lot of apps that could just as well be webapps.
Particularly excited to make a PWA with Qwik City: https://twitter.com/vendure_io/status/1600412989642878977
That now can also have push notifications. And pretty sweet Shared Element Transitions (could even be used in MPA's):
https://twitter.com/dannymoerkerke/status/159718717278369382...
Particularly excited to make a PWA with Qwik City: https://twitter.com/vendure_io/status/1600412989642878977
That now can also have push notifications. And pretty sweet Shared Element Transitions (could even be used in MPA's):
https://twitter.com/dannymoerkerke/status/159718717278369382...
I recently imp'd web push for an internal admin tool, tested on android
AFAICT it only works if chrome has been started recently, and you have to turn off background throttling for chrome maybe. (guessing this is highly vendor, version, and device specific though). But it was fine for something I check daily anyway
Python library support for sending this is present but shaky -- guessing apple's endorsement will improve the ecosystem for this
Not sure about consumer space, but for communicating with technical users who know you well, this is so much of an easier rollout process than an app -- literally 'hours vs months' comparison
AFAICT it only works if chrome has been started recently, and you have to turn off background throttling for chrome maybe. (guessing this is highly vendor, version, and device specific though). But it was fine for something I check daily anyway
Python library support for sending this is present but shaky -- guessing apple's endorsement will improve the ecosystem for this
Not sure about consumer space, but for communicating with technical users who know you well, this is so much of an easier rollout process than an app -- literally 'hours vs months' comparison
Sorry but this is basically worthless until there's a MUCH easier and more visible way to add websites to your home screen.
In a perfect world you could submit your PWA-based site to the App Store where it would appear alongside native apps and be discoverable in search results etc.
But that'll never happen because Apple has way too much to lose from allowing developers to create genuinely cross-platform solutions. They need developers to be absolutely married to their ecosystem so that the users will be too.
In a perfect world you could submit your PWA-based site to the App Store where it would appear alongside native apps and be discoverable in search results etc.
But that'll never happen because Apple has way too much to lose from allowing developers to create genuinely cross-platform solutions. They need developers to be absolutely married to their ecosystem so that the users will be too.
Good to see Apple finally making some effort to support PWAs, but as a user it's still very cumbersome to actually add a Web App to the homescreen (compared to Android).
Going to be great for web based podcast apps that do live broadcasts like Curiocaster; https://curiocaster.com
I recently switched to an iphone, the state of PWAs on iOS is just pathetic. While I don‘t care about web push, I‘m really glad they‘re trying to make some progress in this area.
It's a shame Safari on Mac still does not support web apps at all. I'd really like to have Gmail and a Twitter web apps that I can separately command-tab to.
Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?