Web Push for Web Apps on iOS and iPadOS
webkit.org
webkit.org
Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?
Keep it user-driven.
IIRC (and I may be mis-remembering) they mostly just added that in the first place because sites were hacking in their own (which, on its own, might be fine), and other sites were abusing that dynamic for phishing or otherwise scummy purposes (not fine), since there was no standard look & behavior for those prompts. As long as installing PWAs requires user initiation with actions in the browser chrome, and can't be initiated by a link in site content, that shouldn't be a problem with PWAs.
And that’s all anyone is asking for, which would make PWAs equal to native apps in that regard.
Your fervent opposition higher in the thread seems like a different position.
AFAIK, such prompts are regular HTML with links to the AppStore. If so, how do you suggest Apple make it impossible to add those to a site?
The ones under discussion are not: https://developer.apple.com/documentation/webkit/promoting_a...
Apple controls the experience. The developer just tells Apple which AppID is connected to this website, and Apple chooses how to present this information.
Smart App Banners also react to whether the app is currently installed or not, which random websites obviously should not be able to determine for privacy reasons.
If PWAs weren‘t arbitrarily restricted there’d be no reason to link to the app store because…you’re already in the app.
Spamming users to hit the install button would be like spamming users to bookmark your website. That doesn’t seem to be a problem (though that’s probably because people don’t keep their bookmarks on their home screen)
Now there are a couple nice things:
- if an app is not installed you can dismiss for a particular site and you will never see it again. The website has no way to trigger it, the API is more like “Hey Safari I have an app” than “trigger a prompt”. - unfortunately if the app is installed you can’t dismiss the notification to open in the app. This I quite dislike because many sites have certain pages on their site with no equivalent in the app. Sometimes I have an app and just want to visit the site without being nagged.
For Chrome (desktop or mobile), if you have similar attributes in your manifest.json, then Chrome will show the 'Install' button to install the webapp to your home screen.
And very often I'd actually prefer a PWA, e.g. if I know that I'll be using a given site/service exactly once. Common example: A flight or train ride with a carrier I know I won't be using again anytime soon, but still would like to get notifications relevant to my trip.
I don't understand this at all. Lack of push notifications is one of the biggest reasons why I still have a number of native apps installed, apps that could be sandboxed webapps otherwise. I have heard push notifications on iOS used as justification for building a native app instead of a webapp so many times. I have talked with users about how there are certain services (Facebook, Twitter, etc...) that I refuse to install on my phone, and their response has been, "well, I'm installing the native app because otherwise I won't get a notification when I'm messaged."
I have a hard time believing that lack of notifications or the barrier entry to building iOS apps has made companies more likely to build websites. My experience has always been the opposite, if I ask a developer why they're building a native app instead of a website, there is a really high chance that push notifications are the reason they give me.
----
And there's honestly not a lot of reason for most apps to be native apps at all except that:
A) data storage is unreliable and can get deleted unrecoverably without user prompts.
B) push notifications are unreliable on Android and don't work on iOS.
Email, timers, alarms, every social media site, etc... How many native apps are on your phone -- apps that have much greater access to your hardware and that can fingerprint you with a lot more ease -- that realistically never needed low-level access to your hardware in the first place, and are only native because that's the only way to provide notifications or work reliably without a server?
Honestly, my biggest criticism of push notifications (and part of the reason why I think they're less powerful than people are making them out to be) is that they're server-centric; the push notifications standard has all the fingerprints of Google saying "well, why would anyone ever make a webapp that didn't have a backend?" If there was a reliable way to schedule notifications/alarms offline without ever going through a server at all, and if there was a reliable way to store user information where I didn't have to worry it would magically vanish unless I backed it up to a cloud, I think I would be able to uninstall something like 50% of the apps on my phone and replace them with trivially small Javascript apps. And whenever a company tried to give me some bloated mess, I could run an adblocker on top of it or just deploy my own replacement.
And that would be a really good thing. It's good that (for example) Wordle is a PWA because I can run an adblocker on top of it. Wordle is far better as a PWA than it would be as a native app. Similarly I honestly should not have to install an alarm app on my phone; that does not need direct access to my hardware, it can be a webapp. Except it can't, because there's no way for a user to allow a website to schedule an alarm.
I too want to just use mostly websites instead of native phone apps, and I too don't want my data sent to a bunch of random servers someplace. I don't understand how people think that blocking basic functionality makes companies less likely to require native apps though. The reasoning does not make sense to me; I don't know what I'm missing but the argument seems like it's saying that making something easier will make fewer people do it? I don't understand that logic.
----
Edit: Ok, charitably, if the argument is that this will make more of the limited webapps that exist today ask for additional permissions, then yeah, I see that.
But A: most of those companies were trying to get you to install native apps before
B: having those companies hand you a webapp gives you much more control over what they're doing, including doing things like blocking prompts and setting up extensions to block their nag methods, which you can't do natively.
And C: it sounds like Apple is basically duplicating their install permissions for notifications anyway, which I think is a very sensible approach.
It would be good for push notification to be revisited as a standard, because I think it's a kind of terrible standard? But it would be good to revisit notifications in general. And Apple's approach, which explicitly wires push notifications up to obey the same permissions and settings as native apps, seems like a good step in that direction.
It wouldn't surprise me if the trend we've been seeing in iOS where notifications are deprioritized continues in iOS 17, including some kind of mechanism that deprioritizes notifications from the spammiest apps and sites unless the user has explicitly marked them as important.
> more ways for a site to shove things in front of me
The prompt can be provided by the browser, at a moment of choice for that browser, in a standardised way, and with the option to be disabled globally. For example, a browser could choose to only show the option once for websites you use often and provide a manifest file, and/or when you bookmark them, and/or just show an icon in the address bar. So many ways to do this in a nonobtrusive way, that still makes sure that people who would be interested in adding it to the home screen (i.e. a subset of the people installing an app today) actually know they can do that.
I's long overdue to have them treated as first-class apps, though (i.e. allowing having them only in the app library and treating the home screen as an optional short cut only)!
While Apple don't invest in PWA, PWA is doomed from a commercial point of view.
It is a really sad situation because the user experience of PWA is match better than installing apps from the store (with higher install rate than native).
Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.
Something is very wrong if you can't tell the difference. The difference is night and day on iOS.
PWA app has significantly lower responsiveness, constant mis-touches on buttons, loading screens for every click etc.
That's certainly not inherent to every PWA, e.g. there is no need to have a "loading screen for every click".
People have A/B tested "click this app store link to install" and "click this to install this webpage as a web-app" and found the latter gets more installs?
I can't believe people keep saying this with a straight face. It's as if they've never seen an proper native app before (any of the third-party clients to Twitter come to mind before they were axed). Or haven't seen actual good fast implementations like the one Twitter actually bought and surprisingly still kinda maintains (see on desktop, https://tweetdeck.twitter.com/)
Websites are not randomly asking for mic or camera because that would be creepy and visitors would just run away.
I am not lecturing, I am giving my feedback on the matter, like everyone else here. If your product is good, users will save your site in their home, don’t worry about that.
I thought it was fairly straightforward to add an "add to home screen" overlay to a webpage with javascript.
On Android, yes. On iOS, users have to click “share” and “add to Home Screen”, which practically nobody knows how to do, and it presents the user with a rather confusing prompt for them to choose the name of the PWA they’re about to install. The website could tell you to do that, of course, but then it only works in safari at the moment, and it is very clunky.
iOS allows websites to show a banner that will help them install the equivalent app from the App Store, but there is no similar functionality for PWAs.
Some people speculate that Apple relies on the PWA install process being confusing to help push developers into the App Store.
Regardless of it being auto-populated, I think being immediately presented with the option to choose the name will inevitably confuse many users. If the user accidentally hits any keys, that will mess up the name... then they have to try to fix it themselves, if they even notice before they hit the "add" button. That just doesn't seem like a great user experience.
Talking about the "add" button, it is not called "install", unfortunately. The "add" button by itself may confuse users into wondering if they clicked bookmark by mistake. In fact, the interface is nearly identical to the bookmark interface in Safari, except that the bookmark interface uses the word "save" instead of "add", and the bookmark interface shows you which folder you're saving into. How clear and simple!
The "add" button is also a small button in the top right, which is completely different from how the "GET" button with a vivid blue background is presented in the App Store. Renaming and restyling the button to match the one in the App Store would make the experience more consistent for the user.
None of this matters to technical users like us either way, but making PWAs more accessible to all users requires making the process as easy as possible, smoothing out weird rough edges like this. The option to edit the name would make more sense under the Settings app or maybe an additional "Edit" option in "jiggle mode" on the home screen, if it should even exist at all. I can't edit the name of other apps on my phone. From a technical perspective, someone might ask "why can't I edit those names too?" But, it should be consistent either way, in my opinion.
Those are my opinions on the current interface, anyways. I don't think Apple has meaningfully changed it for over a decade, and if they have decided to care about PWAs, they really should polish this interface up.
Thanks very much for your detailed explanation. Man, more and more I don't know how people can continue to praise Apple for better usability. So much shit on an iPhone these days is in completely hidden, non-obvious gestures or swipes - e.g. why TF would anyone think "add to home screen" would be in the share menu?
I keep seeing this touted as fact, yet no one has ever provided any evidence. I have the feeling everyone who says it is just mad at the feature not being there and they ascribe to Apple the most damming justification they can come up with.
Apple is greedy, especially under Tim Cook, but that doesn’t mean every decision is primarily motivated by it. Sometimes the people at Apple truly believe something is the right choice for the majority of users. Maybe you’ve been lucky to have never seen a relative’s device full of spammy web push notifications they don’t know how to turn off, but that is not rare. You can find reports of it among the other comments.
It would great if Apple similarly supported PWAs as first-class citizens in the App Store. It would also make a lot of sense: it would still favor the App Store as the "primary" or "best" way to install apps, and users would keep a lot of familiar experiences in choosing to "install" apps (much more familiar than Share > Add to Home, as other comments around here point out). Apple can even still try to curate the listings to keep them looking nice and staying informative (and whatever quality insurance checks they like to run). The users don't need to know or care that an "app" in the App Store is a PWA or not. Same with all the normal "Install Our App" and "Find this App in the App Store" links and prompts and modals (and "paywalls") those can/should all be the same experience whether the app itself is powered by Swift (or anything else) or powered by a PWA. Users that install PWAs via an App Store think they are still sommewhat locked into that app store's moat because they still think of that app as originating from that App Store. It's something of a win-win for Apple, I feel.
Not as a replacement for a general option like Share > Add to Home, because there will always be PWAs with no interest in submitting things to App Stores (and users will always want nice home screen bookmarks even for non-PWAs), but as a way to unify the install experiences for PWAs that do care about install metrics and app-like branding the best thing Apple could do (both for users and themselves) would likely be to allow developers to just submit their web app manifest URLs as the only "application code" in an App Store listing.
I agree. See also: the way you can't directly open an HTML document from Files (you essentially get a blank screen, even if all the JS and CSS is located in the HTML file).
If the site wants to tell me I can install the PWA by adding it to my home screen and remind me how to do so, it's welcome to, but no unwanted popups/prompts.
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
Since users tend to choose the path with the lowest friction, they'll probably prefer to find a way to close a pop-up. The instructions also make it very clear what the user would sign up for.
Bonus: Don't even let the web app know whether the user has subscribed to make it impossible to force.
And there's no understanding among a lot of web standards people that popups for site permissions are widely used by malicious actors. Apple consulted the community and thought about security, and that's why this implementation is refreshingly better.
If the user doesn't know how to enable those permissions, then they also very likely don't know how to disable them either, which is a problem. If they don't know those permissions exist, they also probably don't know what the implications are of turning them on. Giving them a bunch of yes/no dialogs to click through doesn't change anything about the obligation to educate users about their device permissions, and if they are educated properly then they can set those permissions themselves.
Google (and browser manufactures in general) kind of taught people that the way we do permissions is that apps ask for them and the user says yes/no, and the app responds. It's not entirely only their fault, but it's the wrong way to think about it in my opinion. I'm not even sure I like the word "permissions". Most permissions should be better thought of as "capabilities" and they should be something granted by the user, not requested by the app, and the app shouldn't be able to tell the difference between a phone/platform that doesn't support those capabilities at all and a phone/platform where the user has denied those capabilities.
A lot of issues about how permissions aren't scalable or how they don't work stem from the way we think about permissions as if the default UX for them should be that they're handed to the user like a EULA to sign.
----
I'm still bitter over the fact that Chrome blocks webaudio behind a user action and literally breaks the website audio if you accidentally set it up when that permission isn't granted yet, and then disables all of those protections whenever you navigate pages within a domain. It's ridiculous; what should have happened is that by default, tabs in Chrome should just be muted globally, and audio code should just continue to work normally so that a massive number of web games don't just immediately break, and the user can untick the mute button and turn on sound for the very, very few websites where most users want sound.
I'm bitter that they made all these justifications about how blocking the audio was important because it would save mobile data, and actually what happens is all of these sites just mute the audio by default, stream the video on mobile data anyway, and then unmute the video as soon as the user clicks anywhere. It's a bunch of bad justifications for a UX that makes it easier for websites to abuse users. We could have had more user-friendly behavior and not broken the entire web, but Chrome wanted to try out some weird statistical model for blocking/allowing audio playback instead of adding a button.
The "spamming requests for things the user doesn't care about" problem is a lot easier to deal with if you invert "permissions" into something the user requests and not the site.
However, nagging the shit out of users should not be the default behavior. They knew that this feature would get abused by every sleazy webmaster on the planet as soon as it was supported in popular browsers. The feature should have been properly designed in the first place. Now I'm content with letting it die.
I appreciate Apple's willingness to more or less ignore open standards that hurt the user experience more than they benefit it.
Note that that behavior might be different on mobile vs. desktop browsers, but again, I don't really know how to test, sorry.
IIRC this used to be against Apple App Store rules but I guess they got relaxed for spamming existing customers.
Fastest way to lose me as a customer, TBH, is to disrespect my fiercely-guarded attention span with prompts to spend money while I'm busy being focused on making it.
It was.
> but I guess they got relaxed for spamming existing customers.
Apple themselves have sent notifications of that kind. The rule has since been dropped, I doubt it was ever enforced.
Sure it’s still better to never subscribe to unwanted notifications, but removing them isn’t much of a hassle in the current system IMO
I'm being a bit over the top here but I consider it much the same problem as how you might use a car without understanding any of how it works. In the same way, plenty of people own mobile phones without any understanding of cause and effect.
I'm pretty sure my parents don't even "see" permission prompts, they just sort of have this "thing" in the way of the "screen" and tap at it to go away rather than y'know, some sort of two way consent dialogue.
My feeling is that if a user doesn't know how to disable a permission, then they were not giving informed consent about enabling the permission. Being able to turn on a permission is an imperfect but ultimately better indicator that they likely know what the permission is (it's not completely bullet-proof, but it's better).
Clicking "yes" just means that they clicked "yes", it doesn't mean anything more than that.
I wonder if a similar approach could be used: just as users might half blindly push "OK" on a request for notification permission, it could be counter balanced by a check on new notifications in the kind of "Do you want to stop this app from sending you more of these messages ? you can always change your mind in the XXXXX screen <link to said screen>"
To be honest, I don't wish for more people to have to comb their notifications screens and have a deep understanding of what's happening. I'd prefer the OS to better surface to the user they just need to push a button to get rid of the crap.
Not install prompt banners like in Android* but right now you have to use the Share screen. It almost feels like Apple is hiding that functionality so that users don't find it. Installing and sharing are two very different actions.
* I'm an android user and I agree these are bad.
All in all, text selection and search is still such a second class experience on iOS.
So, back on-topic, it does kind of make sense in that you’re taking the current URL and sending it to the Springboard.
The best example is Photos, where the Share Sheet would have a LOT of unrelated junk — Duplicate, Hide, Slideshow… But as of one or two major versions ago, there’s now an ellipsis menu to keep those options instead. Notes got the same treatment.
In current Safari, the “aA” menu is an equivalent of that. In my opinion, “Find on page” is really the only option on that Share Sheet which doesn’t really belong. All the others make sense, as they’re an “Export” of the page in some way or another.
In theory Safari's tab context menu would be a better fit, but given it iconifies as a "change text size" tool, I don't know if that would really address your concern at all.
It’s relatively unobtrusive and easy for users to dismiss.
[0] https://developer.apple.com/documentation/webkit/promoting_a...
Disadvantages:
- cannot hide that folder in the App Library
- limited number of shortcuts per folder
Could be a feature of iOS 17, which will be available to developers at WWDC in June.
It was such a hassle doing support over the phone (She lives in NZ and I was in Singapore, and now Taiwan)
Bought her an iPhone 12. Apple support helped her set it up over the phone. 2 years and I haven’t played IT guy once!
I do not want to have to go chasing “where did this annoying notification come from” game… ever.
Other people I think it is an issue.
I'd be shocked if the vast majority of "use" of the "feature" weren't exactly that kind of spammy, unwanted messaging.
It presents a modal popup asking for permission. A few times I have accidentally clicked "Allow" only to have to hunt through my notification settings for the offending website to remove it
Web sites should not be allowed to present modal, native UI that can interrupt the browser. They should be contained to their window
A better implementation would be to allow the browser to show a bell or other icon in the main UI indicating the website offers push notifications. Clicking on that would inform and allow the user to opt-in
I can't think of a single valid use case for them. There are only a handful of desktop apps (literally 4 or 5 apps like MeetingBar) that I allow to use notifications on desktop. For essential messaging app, etc. that I need notifications on, I configure them to be only on my phone, which I can just turn over if I don't want to see them.
This new iOS functionality therefore fits perfectly with how I use notifications: if I install the website like a mobile app, it can maybe get notifications, otherwise websites can't bother me even with requests to show them.
I like that I didn't have to permanently disable push notifications in Safari to stop those awful popups asking if I wanted them. Apple knows that people will say "no" 99.9% of the time. It makes more sense to make the user jump through hoops the one time they actually want it than to incessantly nag them every single time they make the mistake of visiting a new web page.
But this is a different kind of problem and no reason to slow down the Push API standard.
I'm very happy that they also finally implemented things like Screen Wake Lock API so developers will no longer be forced to do silly things like play a fake video loop in the background to keep the app in focus.
Looks like Apple is finally going to give PWAs some love and it's a good thing overall.
Chrome does let you do it though.
Does it though? I still get asked to opt-in for notifications on websites regularly, including those I've already said no to. A simple opt-in question still makes me answer the question routinely (with the default "Sites can ask to send notifications" setting).
This puts a much higher bar on the notification opt-in game.
And if you accidentally click yes, it even has a section in the 'safety check' section that will have a list of sites sending you too many notifications.
Also, there's another setting where you can toggle between: ask permission, block all; and some other silent blocking them....
I wonder if it remembers my settings better because I have a google account that my chrome is logged into for syncing these things?
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
HUGE! 4x speedup for anything parallelizable. This should bring around ~45GFlops out of the box in the iPhone browser, which isn't much but easily enough for basic neural networks (think object tracking, background segmentation, face feature tracking). For comparison, WebGPU would get that to ~1000GFlops
A great example would be JSON parsing in WASM apps where SIMD algorithms result in massive speedups.
Another example would be a WASM software decoder could allow AV1 playback content on iOS browsers.
Currently no Apple device has hardware AV1 decoding, so why support it in Safari iOS Beta? Perhaps next CPUs (A17 and M3) will have dedicated AV1-decoding hardware? Either way I think this is a hint it may be supported soon.
Great news!
That was half a decade ago, when they joined the Alliance for Open Media: https://9to5mac.com/2018/01/04/apple-alliance-for-open-media...
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.
That's of course not in Apple's control, it's just a meaningful downside to opening up push notifications to web apps on iOS. The utility for the few apps that can really benefit from this probably outweighs the downsides, but I've seen other people's phones and know it will also, and possibly mostly, only contribute to more spam.
I can think of so many valid and proven use cases for notifications.
Requiring to first save a web app locally in order to actually benefit from its full feature set is bad UX. Apple.
There are many native apps on my phone that abuse notifications for spamming (often by not having an option that disables marketing while keeping e.g. delivery notifications active, which means blocking everything is sometimes not an option), but at the same time, there are some websites where I'd really like getting notifications (and notifications are in fact the only reason I have their app installed!).
They shouldn't, which is why I think this is an overall positive change. It's mostly that when you add ways people can receive notifications, it can only increase the amount of notifications you can get, not reduce it, and notifications for most applications have at best dubious utility for the end user.
Web apps are also not beholden to the app store rules, so I think they at least have slightly higher chance of being abused, not that the app store prevents companies like Uber from spamming you with advertisements and bundling them with delivery notifications, like you mentioned.
The key issue (as many others have noted) is that the "installation" step is still somewhat arcane.
They own the browser. They can theoretically maintain a list of bad origins just as much as they can block an app from the App Store.
They aren't very effective, then. I'd love to have a way to let (e.g.) food delivery apps tell me when my food is arriving, without letting them spam me 30 times a week with "special offers".
> 2.5.3 Apps that transmit viruses, files, computer code, or programs that may harm or disrupt the normal operation of the operating system and/or hardware features, including Push Notifications and Game Center, will be rejected. Egregious violations and repeat behavior will result in removal from the Apple Developer Program.
> 2.5.16 App Clips, widgets, extensions, and notifications should be related to the content and functionality of your app.
> 2.5.18 Display advertising should be limited to your main app binary, and should not be included in extensions, App Clips, widgets, notifications, keyboards, watchOS apps, etc.
> 3.2.2 Unacceptable: (ii) Monetizing built-in capabilities provided by the hardware or operating system, such as Push Notifications, the camera, or the gyroscope; or Apple services, such as Apple Music access or iCloud storage.
> 4.5.3 Do not use Apple Services to spam, phish, or send unsolicited messages to customers, including Game Center, Push Notifications, etc.
> 4.5.4 Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. Push Notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app’s UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges.
----
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.
Looks like this effort died because of Android: https://bugs.chromium.org/p/chromium/issues/detail?id=891339
I really think Google made the Web Push standard worse, in multiple ways.
https://developer.mozilla.org/en-US/docs/Web/Progressive_web...
But you can get that behavior... if you set a web server and force the user to make an account and then log all of their habits in your server and then send out the notification yourself. Because... it's unfair for me to blame Google in this instance, I don't know it's their fault, but I do blame Google and I suspect it's their fault. I could be wrong though.
But even then, the UX seems pretty bad; when I first created an app with web push, a few years ago, there was zero guarantee that notifications would ever show up, and they seemed to fall through very often, when the client (at least with Firefox Android) sits in the background; https://stackoverflow.com/q/60809681
i can't tell if the situation has improved recently -- anecdotally it seems like it's a bit better now -- but depending on what sort of notifications you want to push, that quickly becomes a complete showstopper.
That could also be a longer conversation, but yeah, that was also my conclusion, and again... I don't have proof that this is Google's fault, but it stands out to me that notifications as they're built today are primarily useful for spammy advertisements and engagement requests and are extremely unreliable for everything else.
If your primary use case for notifications is telling the user that your blog published a new article or reminding them to check into their account or advertising a sale, then notifications are great; and you don't really care about reliability in that instance.
If you want notifications to be something the user can really rely on, ie calendar appointments, sign-in attempts, etc... they don't seem like they're trustworthy enough to do that.
Of course, we need those OS-level restrictions around notifications to stop abuse and spam, but that's only because it's super-easy to start spamming the user in the first place. And my pet conspiracy theory is that Google on some level looked at notifications and said "it's more important that it be easy for a blog to get somebody to click yes on this, than it is for us to build a transparent process to the user that would allow us to make the delivery more granular and more reliable." Instead of making it harder for websites to get notifications permissions in the first place, Google made them less reliable; the model is that you will have a bunch of sites that can spam you but they'll spam you unreliably.
Again, I can't prove that, and maybe things have improved, but it's just weird how the entire spec seems designed around advertisements/spam, even to the detriment of everything else.
That's a good suggestion, I should play around with that some time.
Nobody uses the mac app-store anyway, so why bother? Why not do it?
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.
Before the iPhone was released, a typical mobile web experience was a separate site that barely worked and didn’t use any normal browser technologies. Along come Apple, who do a tonne of work to make their open-source WebKit work well on mobile, and virtually overnight all smartphones adopted WebKit to catch up with them.
Anybody who doesn’t think Apple has done more to advance the mobile web than practically any other organisation should be forced to build WAP/WML mobile sites until they repent.
They didn’t do it alone of course – WebKit was originally based upon KHTML, and I believe Nokia also had a WebKit-based mobile browser. But Apple put a tremendous amount of work into it and the dramatic shift from “the mobile web is shitty and worthless” to “the mobile web is actually useful” happened almost straight away as a direct result. Nobody wanted mobile websites / mobile web applications before the iPhone came out, then all of a sudden it was a normal requirement for a site to work well on mobile.
Unless some (unknown to me and possibly everyone) change happens and PWAs explode in popularity… there’s going to have to be a reckoning that end users just don’t seem to care/want them.
They can still be useful but the dream of abandoning the app stores (due to PWAs) just doesn’t feel realistic to me.
This phrase is far more prescient than most people think. Yes, it's a numeric minority. However, they have a near-monopoly on _profitable_ users. 13% of the global market and >50% of the profits.
> You do not need to be a member of the Apple Developer Program to use it.
Wow.
The EU is forcing them to allow side loading so they are racing against the clock to try to bring WebKit to a point where everyone is not just going to switch to Chrome overnight when that happens.
[EDIT] Web app developers, that is—users of the push system. And it means when end users have 20 sites sending them pushes that they don't want, they'd have to figure out how to disable them in Chrome's settings, rather than their normal system push settings. It'd be a total mess.
Or are they Effectively dependant on each other?
Yes this is a significant hammer blow against native apps on iOS, but I don't think this would reduce cost for the consumer. I might be misunderstanding what you mean by "freely accessible" though. Definitely is more convenient for the same web app to be available everywhere.
Funny how this significant blow never happened on the world's most dominant OS where all the restrictions that HN loves to whine about don't exist.
True on Mac, not on iOS. Apple doesn't let you ship custom web renderers. You need to use the system's built-in one. This applies to browsers such as Chrome and Firefox too!
Source: https://www.macrumors.com/2023/02/07/mozilla-developing-non-...
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.)
As an aside, I dig the design! It reminds of teletext haha
That page also talks about "What to Cache" here[1], and it specifically suggests that most apps will want to cache the main page's HTML.
Now that iOS will supports push notifications in PWAs, I definitely plan to try out the developer experience again soon.
> I still want the address bar with the manual refresh button. But I can't do that.
Yeah, I mean... you're meant to provide an app-like experience if you're doing a PWA. You could certainly build your own stylized, floating bar that only shows up in PWA mode, or think about new ways to let users control the way the page updates. Alternatively, you could just automatically refresh the page with a setTimeout?
I'm not sure how much you want to invest in experimenting with the technical foundations of your app, but I wrote out a few ideas that occur to me:
- Your Cache-Control header is kind of weird. `max-age=15`. I would expect to at least see a `public` or `private` directive in there to specify how this data is supposed to be handled by intermediate proxies. Something like your website is a prime candidate for caching in a CDN layer, and I think you generally want to specify `public` for CDNs to do anything useful. Maybe they default to `public`? I've honestly never felt the need to try. Beyond the `public` / `private` discussion, `stale-if-error` could be useful so the CDN could serve the most recent info even if your application is having a brief outage. If you're not using a CDN... probably something worth checking into.
- As cool as just serving self-contained HTML document is, your page is still transferring 6 kilobytes each time it refreshes. If the goal is to lower that as much as possible, I would start by pointing out that you don't need to send your JavaScript snippet every single time the page loads. It looks to be several thousand bytes uncompressed, although I'm not sure exactly how much it is affecting your compressed payload size. You could separate that into an aggressively cached JavaScript file that is served separately from the HTML. (As usual, best practice is to have a file hash in the name of the javascript file, that way the cache time can be infinite. If the javascript needs to be updated, the hash would change, so the browser wouldn't have that cached, and would fetch the new file immediately, as soon as the refreshed HTML file requests it.)
- But then after that... the next logical step is to render the actual score interface client-side, since the score data is significantly smaller than the HTML needed to render the score data. This would also allow you to handle refreshing more elegantly from the client by just fetching the data route that returns a JSON blob, and re-rendering the HTML. At this point, the HTML representing the empty app shell could be cached too, but it would probably be best to limit the cache duration depending on your preferences. The right value for HTML caching would likely be somewhere between a few minutes and a few days. Now, opening the app would load the locally cached HTML and JavaScript, and then the JavaScript would just fetch the tiny blob containing only the scores and nothing else. Of course, you could cache this information locally so that when the PWA is opened, the user can always see the last information (and when it was fetched) even if they don't have an internet connection, while the PWA can continue trying to fetch the updated scores.
- Taking this to the extreme, the maximally efficient design for something like this would probably involve an SSE (server sent events) endpoint that the client would subscribe to. Whenever the scores actually do change, the server could push that straight down to the client. This would reduce the latency from your current 30 second target, and it would also use even less data since people aren't refreshing and receiving the same stale data multiple times. (I will note that a good implementation of this would still send a tiny ping from server to client every minute or two just to ensure the connection doesn't get silently dropped by any weirdly configured firewalls along the way.)
- If you were really going all-in on features, well... this whole HN discussion is highly focused on push notifications, so you could always let people subscribe to specific teams, and send them a push notification when scores change for those teams.
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.
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.
The only way to even find out if a website actually offers a PWA (assuming you know what that is, which is probably not true for >90% of users at this point) is to add it to your homescreen and then see if you get essentially just a bookmark, or an actual PWA.
I guess Byzantine is the wrong word. It’s not discoverable because no one knows what they’re even looking for.
I'm also curious how badging would work for non-home screen apps?
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 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 seems to be doomed to persona-non-grata for a lot of developers. At least until the Chrome worship dies.
That said, I wonder if alternative browsers will actually get access to the "add to homescreen" API?
If it's available for webkit-based third-party browsers now, it seems like it would probably be available for non-webkit browsers as well. Maybe not, but at least the door is open for it. It would be hard to justify the limitation.
Apple would never let that slip in a WebKit update post.
It would get a ‘real’ announcement somewhere. Keynote slide, iOS features page, App Store rules update, flat out press release, etc.
There are also open source webkit builds like GNOME Web (though they're quite different from Safari in many ways).
Not afiliated.
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?
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.
I work with custom web map apps, so it is great that iOS is moving little bit closer to Android.
PWA install prompt would be great like in Android. Share - Add to HomeScreen is too difficult for many users.
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...
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
It's possible extremely aggressive battery savers or extreme power saving modes will kill these services as well and require Chrome to start, but you shouldn't need to launch Chrome manually in most cases (or Firefox, or any other browser).
There's simply no way to fix this restriction, not on the web nor on native apps.
I'm on up to date droid OS with an older pixel device
I wonder if 'aggressive throttling' is the norm on older devices? Also, I remember reading about a non-google android handset vendor who shipped custom throttling logic (but don't quote me on this)
it's been a while since I tested, and because I don't know how to inspect the daemon state directly, I'm not sure of any of this, but iirc:
1. I had to switch chrome to 'unrestricted' from default 'optimized' in the OS settings 'app battery usage' screen, or else notifications would fail starting a few hours after the last time chrome was foregrounded
2. chrome had to be started once after boot (less sure of this)
it's certainly possible something else in my stack is causing problems, or I have misconfigured retry on the send-side
I'm still on a heavily modified Android 11 and my phone is receiving browser notifications fine, reboot or not. I know many of Google's pixels contain relatively weak CPUs to keep cost and battery consumption down, but that shouldn't be a reason for Chrome to keep crashing in the background.
You can try going to chrome://serviceworker-internals/ and checking for any weird background service workers that may interfere with your browser. That page can also be used to troubleshoot serviceworkers (which can/are used for sending notifications).
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.
I’m on an older OS with an older version but I love it for creating single-site apps.
*Not to be confused with users' ratings and reviews
Home Screen dependent.
Just for clarity, sounds like this functionality only exists for web apps added to your Home Screen.
(Which I think is fair, but just pointing this out since I don't know how common it is for people to add web apps to their Home Screen)
The flexibility of multiple instances separated by manifest ID is great! But it makes universal links challenging. Would need to include the ID in the URL path?
Does anyone have any sense of how long it might take for this get out of beta and widely supported by iOS/iPadOS devices?
Given this is public beta one we may see the release near end of March (total guess on my part). Point releases don’t tend to have too many betas. And Apple ID itching yo get the HomeKit new architecture bug fixed soon and that’s in 16.4.
We'd expect most sites that support standalone mode when added to the Home Screen and support Web Push to Just Work™
3 real world examples are lichess.org for Chess fans, elk.zone for Mastodon fans, and twitter.com for those that still actively use Twitter.
This also has big implications for the hegemony of the App Store and Apple’s control over the web platform. I don’t fully understand why they are finally giving up this power they have held onto for about 8 years, but I’m glad they are.
No it doesn't. It will make zero difference.
Because developers have been building web based mobile apps for nearly 15 years now. And they never took off not because it lacks push notifications or some other minor feature. It's because the end user experience is terrible.
And I've yet to see anything that addresses the difference is latency, responsiveness, feeling etc that you get between native and web apps.
The difference that web push notifications will make is infinitesimal.
For the record, on Android it's also shitty, but not this shitty.
And ever since Apple have actively tried to destroy the advancement of local web apps.
Now the writing is on the wall with regulation of their App Store they are finally pretending to embrace PWAs.
I don't know anything about WebKit development processes or community management, so please forgive me if I say something wrong. Isn't it interesting how the engine has been implementing new features and generally running on a lot of steam coincidentally since the EU's Digital Markets Act (which will force other web engines on iOS) went into effect?
Or maybe the dev process and community interactions has always been like this, in which case disregard what I just said and feel free to correct me.
https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...
No, and previously you could add a hacked website to your homescreen and Apple couldn't stop you from doing so. Not speaking for the other features, but the webpush api provides no mechanism to steal info as much as it provides a way to alert a user who previously installed the app and allowed notifications that the app is sending them a notification.
Now, if after the user installing and allowing, the site gets "hacked", the hacked site operator could send push notifications that invite the user to interact with the compromised web site/app. Apple has no recourse; the pressure would have to be applied to the hosting service to shut down the site. That's a tall order for your average web user.
As an aside, how would a notification steal your info?
https://developer.mozilla.org/en-US/docs/Web/API/ScreenOrien...
In many cases, you have a perfectly functional web app and the only feature you would gain from publishing a native mobile app would be push notifications. Apple used to gate this feature behind its app store/developer program. Now you have an alternative, and I think it was long overdue.
Their previously leaked internal debates about openness and iMessage for Android in particular is fascinating. Would love to see it on this topic.