I have been waiting for this for years! Now the only thing that's really missing is an install prompt. I wonder how long we have to wait, the install prompt is crucial, but I view Apples reluctance to implement the install prompt as politically driven. They want to favour their AppStore and make installing Web Apps unnecessarily hard.
Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?
Ugh, no. It's bad enough they can pop "THIS SITE IS BETTER IN THE APP" shit. The last thing we need are more ways for a site to shove things in front of me to make my day worse.
OK, then the mechanism that let's websites prompts to install apps should be removed so apps are on the same level as web apps. Otherwise, the situation is part of the anti-competitive lock-in. If that won't be removed--and we know it won't be--then this feature needs to be added and will not make the situation worse: it will just mean that there is a hope that some of these websites prompt you to install a website instead of an app. If you want to stop getting prompted to install anything at all, then you need to either remove support for push notifications from apps--which obviously will never happen--or add support for push notifications to random "uninstalled" websites. (And if you don't like being prompted to activate push notifications for things, there should be a global switch to disable that feature... as they say: this isn't rocket science.)
I'd love that, 90% of the ones I see are just from forum sites that use software that automatically provides some terrible "app" that no-one in their right mind would want, anyway.
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.
> 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.
I don't want INSTALL THE PWA spam-prompts everywhere. But, I like being able to open app store links from the browser. My ideal world is not terribly friendly to PWAs. I might use them, but I do not want them to be able to prompt installation actions in the browser. My persona UX is best if they cannot, but if "real" apps can. Second-best would be if neither can (and that's not that much worse—I'd be OK with this). Worst, by a long shot, is if both can.
If both require "share -> install app" or "share -> install web app" (depending on what the site offers) that would be probably my single most-favored solution. Totally fine, both on equal footing. I do not want PWAs to be able to trigger prompts or provide links that initiate PWA installation, even if native apps continue to be able to do so, "fairness" be damned (fairness, in this case, harms my UX because this functionality is guaranteed to be spammy—the "install the native app" prompts are already spammy enough, I don't need more of that). That would definitely make the mobile web even worse than it already is.
What I'm opposed to is letting PWAs prompt for installation. That would be bad, no question. Removing native apps' ability to do so is fine too, IMO, but would also require removing the ability to link to the app store at all to not open up other potential issues. If that's the cost of keeping PWAs from being able to prompt, cool, go for it. But please no PWA "click to install" prompts. No no no.
There is no shouting in these Smart App Banners. The entire user-visible experience is completely controlled by Apple. It is just a passive bar at the top of a webpage that informs the user of the option, which they can dismiss. It isn’t jumping up and down, it isn’t playing loud sound files at the user screaming at them to click it.
What really sucks is when websites like New Reddit provide their own custom modal prompts that cover the webpage and push you to the app, and they’re extremely hard to dismiss and oftentimes these half-baked implementations are broken even if you accept their suggestion to open the app. That type of prompt is not relevant to this discussion, at all. They can do that no matter what you think and no matter what Apple implements. The way you have been talking about these things makes me believe you think those prompts were what is under discussion. They’re not. Smart App Banners are not shouting “INSTALL THE APP!”
I’m personally surprised that Apple doesn’t offer a setting for Safari to disable Smart App Banners, which would be a simple way to stop annoying the few users who are bothered by them. I see at least one safari extension which claims to do this, but since this passive banner is extremely unobtrusive, why bother?
I’m immensely bothered by all sorts of ads and anti-features, but just knowing if there is an app is a legitimately useful thing, so this does not bother me. Even calling it a “prompt” is a stretch since it does not require any action to dismiss. It is a very light “call to action”, of course. If I’m browsing a website I don’t care about and they use this feature, I can ignore it or hide it. It doesn’t get in the way. I'm fairly certain you can even scroll down and the Smart App Banner will automatically scroll off the top of the screen, resizing the website to fill the entire screen.
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.
For PWAs you could simply not expose a hook to the developer that initiates the install process? It would be like if App Store pages didn’t have URLs. Have the install functionality added to the browser UI instead.
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)
The smart app banners are actually part of the browser. You add some meta tag to your HTML indicating your app ID and Safari shows a prompt outside of the web page to install or open it. Infuriatingly it can’t be disabled, and since it’s not part of the HTML I can’t use a content blocker to hide it.
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.
I still don’t see why “then the mechanism that let's websites prompts to install apps should be removed so apps are on the same level as web apps. Otherwise, the situation is part of the anti-competitive lock-in.”.
Web sites drive this, and can choose whether they let iOS show a “download the app” or a “install on home screen” option. It’s not Apple making that choice.
It'd be Apple artificially giving native apps a boost / penalizing PWAs, like they've been doing for 15 years. Sites want to get on the home screen. If the only viable way to get to the home screen is to make a native app, the site will either be forced to implement a native app for no reason or be at a disadvantage.
Apple pretty obviously can support a similar UI for PWAs as for native apps. If they don't, it's just them doing the bare minimum required by regulators while still keeping PWAs as an uncompetitive second class citizen. And if the argument is that these banners are bad UX and will be abused (because that's always Apple's argument for why something should not be allowed in browsers), then they should own up to it being bad UX for native apps too and remove it.
I’m fairly sure most people would prefer that Apple offers a version of the Smart App Banner that gives users a simpler install experience for PWAs. I think saurik was just humoring yamtaddle‘s perspective that PWAs should not be able to prompt for installation ever, and pointing out that it would only be fair to apply their restriction to websites offering native apps too.
Right now, the install process for PWAs is needlessly obtuse compared to what users experience with a Smart App Banner.
I saw someone elsewhere comment on the number of taps required with both methods, and I would point out that not all taps are equal. The simple, guided flow that the Smart App Banner gives users is tremendously easier for users to figure out than the “Add to Home Screen” flow that currently exists.
It's actually tied to meta tags and the manifest.json. If you have the correct tags, Safari automatically shows the prompt if you don't have the app installed or the open with button to open in the already installed application.
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.
I mean, given that we already have "GO GET OUR APP NOW OR ELSE" prompts, would PWA prompts make things any worse?
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.
Yes, there'd be way more of them, because the barrier to entry (and justifiable motivation for needing an "app" in the first place) would be even lower.
> and justifiable motivation for needing an "app" in the first place
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.
I mean specifically the ability to prompt to install a site as a PWA. If they add such a prompt, then you no longer have to go to the trouble of having an app before bugging the user to install your "app". That barrier's the only thing that keeps the "THIS IS BETTER IN THE APP" spam to a tolerable level, as it is—and only barely.
> And there's honestly not a lot of reason for most apps to be native apps at all except that:
Battery life and performance. Except for the ones that shouldn't be apps of any kind, whatsoever, but just websites, which is admittedly a lot of them.
> I mean specifically the ability to prompt to install a site as a PWA. If they add such a prompt, then you no longer have to go to the trouble of having an app before bugging the user to install your "app". That barrier's the only thing that keeps the "THIS IS BETTER IN THE APP" spam to a tolerable level, as it is—and only barely.
I don't believe this at all. The barrier of entry around building iOS apps is small enough that it pretty much only applies to small developers. What that barrier does is it means that fewer 1-2 person Open Source projects offer replacements for those native apps.
But any company that has the resources to track you and cares enough to get you to install an app, also has the resources to make one. Increasingly, what's common in this space (especially with newer social networks) is to just not have a website at all, and to only provide an app. I don't think those companies will change their behavior regardless of whether or not push notifications are supported -- the only thing that will change there is whether or not smaller sites can get away with offering alternatives.
I also think it's a really bad long-term strategy for us to say "we'll prevent spam by making computing less accessible." Notification/app spam is a UX problem (to Apple's credit, it's a UX problem that it is putting significantly more effort into solving than Android is). That could be a longer conversation, but the solution to this kind of spam from websites is to rethink how we provide capabilities, not to stick random hurdles in front deploying apps. Again, long conversation, but I have maintained for some time that websites (and native apps) should not know what they have access to. It should not be possible for a website to tell whether or not it's been added to a homescreen.
> Battery life and performance. Except for the ones that shouldn't be apps of any kind
Opinion me, most applications (calendars, email, text editors) are just interactive documents. People have this clear line in their head of the difference between an app and a website, but my alarm clock is not special in the way that Blender is. My alarm clock is an interactive document, it could be a PWA and it wouldn't be a problem at all for my battery life. My notetaking app on my phone is an interactive document. It thinks it is an app, but it's not -- it's an interactive document that has been made into a native app because it doesn't have reliable offline storage otherwise.
My contention around mobile devices for a while has been that a lot of websites don't need to transmit data off of my device at all, and it would be better for everyone if they didn't have a backend. Whether that makes them a website or app, I don't know, that's semantics to me. Regardless, the point stands that they should have capabilities available to them (alarms, scheduled notifications, pin-to-homescreen, caching resources) that allow them to be used offline.
> I don't believe this at all. The barrier of entry around building iOS apps is small enough that it pretty much only applies to small developers. What that barrier does is it means that fewer 1-2 person Open Source projects offer replacements for those native apps.
Well, a lot of sites that probably would spam an app if they had one, don't, because they don't have one, for one thing. Also see every single PWA discussion on here for an endless stream of PWA boosters complaining about how it's too hard and/or expensive to write native apps. Apparently it is an effective barrier, if we believe them. It's the entire reason they want PWAs on iOS—to remove the barriers to deploying apps to iOS.
> But any company that has the resources to track you and cares enough to get you to install an app, also has the resources to make one.
It's not about tracking, it's about every single site on the web popping yet another annoying prompt nobody wants. That's already awful. Most of the native-app installation ones are spammy crap as it is. 99+% of the PWA prompts would be, and they'd be everywhere.
> > Battery life and performance. Except for the ones that shouldn't be apps of any kind
> Opinion me, most applications (calendars, email, text editors) are just interactive documents. People have this clear line in their head of the difference between an app and a website, but my alarm clock is not special in the way that Blender is. My alarm clock is an interactive document, it could be a PWA and it wouldn't be a problem at all for my battery life.
In theory webtech can make semi-reasonably-slim "apps" for things like this.
In practice—input latency, rendering performance, memory use, idle processor use, load time, and battery life, are between noticeably and hilariously worse in practically every case.
I'm also a little confused about the alarm clock thing. My phone just... has an alarm clock. As a built-in native app. My Android phones did too, back when I was on Android, though they were disturbingly unreliable (as were the ones on my wife's phones, before I got her to switch)—is that the motivation for the focus on needing 3rd party alarm clock apps? As far as ability to set timers at the system level, sure, a PWA should probably be able to do that, I guess (a web site 1,000% should not). Like, at this point I'd consider a phone without a quite-good built in alarm clock simply defective.
And this, I cannot relate to:
> My notetaking app on my phone is an interactive document. It thinks it is an app, but it's not -- it's an interactive document that has been made into a native app because it doesn't have reliable offline storage otherwise.
My note taking app's... not what you're describing. It's an app. Is has lots of features that an "interactive document" wouldn't, unless that term's so broad that it's just a synonym for "computer program". It also performs a ton better than web note-taking "apps" I've tried, which is part of why I use it instead of a web-based option—that and the features, stability, and lack of jank. Hell, it performs better than most featureful document-editing apps I'm aware of period (unless you dig back into pretty distant computing history), and certainly any webtech-based ones, even if it were in fact just a shell for manipulating an "interactive document"—even if that's true, yes, I absolutely want an "app" for that.
> My contention around mobile devices for a while has been that a lot of websites don't need to transmit data off of my device at all, and it would be better for everyone if they didn't have a backend. Whether that makes them a website or app, I don't know, that's semantics to me. Regardless, the point stands that they should have capabilities available to them (alarms, scheduled notifications, pin-to-homescreen, caching resources) that allow them to be used offline.
As far as this goes, it's worth noting that native apps on iOS have some important privacy-preserving restrictions that I doubt they'll be able to replicate for PWAs, because they're review-enforced, not enforced (because, not enforceable) by sandboxing or other automated measures. Fingerprinting the device? Prohibited for apps (long prohibited—that goes way back). Basically impossible to enforce without review, though, unless you cut access to features and hardware down to almost nothing (ahem). The cross-app tracking, the prohibition of which has (so very delightfully) made Facebook extremely upset? Unenforceable without review. For that reason I'm pretty leery of giving the Web platform any more space to move around in and spy on me than it's already got, and that includes further hardware or OS-feature access. This situation may differ on Android, where it may indeed be the case that apps are unequivocally worse for privacy than websites/webapps—it is, at a minimum, not so clear this is the case on iOS.
> Well, a lot of sites that probably would spam an app if they had one, don't, because they don't have one, for one thing.
This is my contention; the apps that want to spam you about this have resources to build apps. The people who don't are the people you see complaining on HN -- they're not companies.
> It's not about tracking, it's about every single site on the web popping yet another annoying prompt nobody wants.
Then I don't get the problem, because this only applies to PWAs you install. If you're worried about prompts asking you to install a PWA, then... that also is a UX problem, it has nothing to do with capabilities. Both Android and iOS I believe include mechanisms to block websites from over-spamming about PWA installation. The mechanisms could be better, but that's down to the fact that both Android and iOS have kind of a bad starting model for how permissions should work; apps shouldn't really be able to ask for anything without user prompting.
----
> In practice—input latency, rendering performance, memory use, idle processor use, load time, and battery life, are between noticeably and hilariously worse in practically every case.
If you say so? My feeling is that most overhead for most apps is the result of background logic. I'm not sure that how quickly you can render a DOM list matters much for battery life on average. Which is part of why background scheduling is so important, so you can get stuff to stop running in the background.
I'll also point out that most of the native apps on most people's iPhones include webviews already; they're good enough performance to use natively. Yes there are apps where you might really care about this, yes there are apps that I don't want running in a webview. But again, think of some examples here. Is it really a problem for you that Wordle isn't a native app? Do you think that's impacting your battery to any noticeable degree? Do you boot up Wordle and get frustrated by the input latency?
I don't know that I would use a webapp to replace Emacs (although I'll point out that Emacs also suffers quite a lot of latency problems because of its threading/rendering model and because of how it handles syntax highlighting, so I'm not sure it is actually competitive with web performance). But the point is, that's an environment where I'm doing programming on a keyboard. For a notetaking app on a phone? Is keyboard latency even going to be noticeable to you if you're using a swipe keyboard that sends input word-by-word?
----
> I'm also a little confused about the alarm clock thing. My phone just... has an alarm clock.
Maybe iOS's native alarm is better, but the native alarm clock on Android is significantly less powerful than I would like. It lacks the ability to:
- Schedule alarms more than a week in advance (no, I don't want to use a calendar for that)
- Delete alarms immediately after they go off
- Snooze alarms for variable rates of time per-alarm (there's just a global setting)
- Select music/sounds randomly from a list (very helpful for ADHD, consistent sounds get filtered out, so I have to constantly vary what my alarms sound like).
- And a couple of other things, including the ability to easily export/import alarms, etc...
Again, maybe iOS is a lot more powerful in that regard, I don't know.
----
> The cross-app tracking, the prohibition of which has (so very delightfully) made Facebook extremely upset? Unenforceable without review.
It's funny you bring this up, because this is absolutely enforceable in a browser and is already enforced in Safari. Firefox also has fantastic support for domain separation (Chrome as usual is the exception). Facebook was upset that Apple was bringing the native app up to vaguely similar standards to what Safari already has.
Seriously, the reason why Facebook tries to get you to install a native app is because native apps are easier to track and insert advertising into. If the web was easier to track, Facebook would offer you a PWA. I don't understand where people get this idea that the web is easier to track than native, I don't think that's ever been the case at any point, including on iOS. The best argument I can make on this is that making PWAs impossible to use on iOS means that Apple can personally vet all of the code that runs on your device, and that's just not a good security model. It doesn't scale well, as much as Apple would like to say that it does.
Yes, Apple can't manually go after web apps that fingerprint you (well, they could, it just would be very obviously tempting antitrust attacks). But even so, I want to make this very clear -- even if you are on iOS, do not install Facebook. Don't install Twitter. Use their mobile website through iOS Safari. And install an adblocker; I don't think Safari's adblocker API is powerful enough to block ads/trackers on Facebook in specific, but it will work on a number of other webapps that you use.
And bonus points, when apps are annoying you on the web, you can do something about it. You can intercept and block/modify app behavior. Sites like Facebook will make that hard, but... I mean ostensibly you're worried about spam from ordinary sites, and anti-annoyance blocklists work fine on them.
Look, I like the privacy stuff that iOS is doing. I like that notifications here require you to install the PWA, that's a good decision. And I love that iOS is adding more permission structures; better file portals are great, more app separation is great, I love the work they're doing around permission prompts. But iOS is catching up to where the web is, it is not surpassing it. The web is a terrible minefield of tracking, and native ecosystems are worse, and iOS is now very notably and very impressively catching up to where the web is. But if you think a company wants to track you (Twitter/Facebook/whatever) even if you're on iOS, you should not treat the native app as safer than the website.
I agree, every random site will almost certainly be vying for notification screen space via PWA install, which will make these banners practically omnipresent on the commercial web.
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.
Uuuuugh the last thing I want is notifications becoming like email, where it's so spammy and impossible to deal with that automated tools have to start categorizing spam and affecting message visibility, and then important messages start to get lost in the shuffle.
That seems like the unfortunate but inevitable outcome of any unregulated channel between devs and users once it's passed a certain popularity threshold. Time to move on from push notifications to whatever the next thing is to enjoy a decent signal:noise ratio there for the 2-3 years before it catches on with the masses.
The crucial element here is that this indeed needn't be
> 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.
One other thing is necessary too, but this is iOS specific: I need a way to dump these to my App Library off my Home Screen. I searched out a few PWAs to see what the current experience is like, and even if I wanted to keep any of these around, I don’t want them on my Home Screen per se.
I had a response typed out, but I think I’m missing something. What is a hidden Home Screen on an iPhone? I have a one page Home Screen, after that it’s the App Library.
If you add a second page of apps, go into jiggle mode, tap the page indicator dots at the bottom to enter the overview mode, then uncheck a Home Screen. It will still exist, but it will be hidden.
Okay I’m really glad I asked because I did not know about that feature at all, and it does the job even if in an awkward way (adding a second PWA creates a third page when the second one is hidden). The PWA I was using to test iOS/PWA interactions now shows up in the App Library and Spotlight among the app results.
It’s not great, but as compromises go this one is basically reasonable, though Apple should still just let me dump them straight to the App Library. Thanks!
My understanding is that being able to hide Home pages predates Focus modes as it was the poor (and hard to discover) solution to what the Apps Library became (for apps that you needed installed but didn't care to see all the time).
But yes, Focus Modes definitely elevates it to another level when you've got Mode-specific pages.
You can have multiple home screens (you've got 2 or 3 on a fresh installation). If you drag an icon to the right you'll see that you'll get an extra screen.
Hi, thanks! I know this and thought this is what was being referred to too, but coder543 had the real answer up above and it’s pretty good. You should check it out.
I just have all PWAs (that I don't need shortcuts for) in a folder towards the end of my last home screen page.
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.
Not to mention that the opposite is also true where a large number of "native" apps are really just wrapped up web apps and many suffer these same issues.
Part of the reason I'm not more bothered by Apple making PWAs viable is that they've failed to crack down on apps that don't meet their performance standards, anyway, letting those apps get away with just being terrible-performing, non-native-feeling web-app wrappers. That whole class of trash-tier "app" may as well be a PWA, I guess.
I'd rather they kick out every app with an unjustifiably-long launch time or with janky non-native behavior in places where it has no reason to be so, but since they're evidently not gonna do that, may as well have PWAs.
Ultimately, it’s a business decision, because paying for 3x the people or 3x the time to implement one feature on web, iOS and android is not something that people like to do, let alone the headache of coordinating feature parity and release timeline with said teams.
The twitter web app is such a mess. Only slightly better than "new" Reddit, which is probably one of the single worst offenders in the world of bad SPAs.
If it weren't for Narhwal and later on, Apollo (iOS reddit clients) my usage of Reddit would be somewhere between 0% and 10% of what it's been the past several years.
> the user experience of PWA is match better than installing apps from the store (with higher install rate than native).
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'd hope PWAs on Android take at least two actions to install (though perhaps not three). One-tap is how you end up with every user having tons of apps installed they never intended to.
> Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.
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/)
I wonder when you people will stop thinking with your marketing/growhacking/SEO/spam brain and start being on the user side. If you want low value visitors just go and buy ad clicks, thanks!
I strongly disagree that what he is asking is user hostile, just like asking microphone or camera permissions aren't user hostile. You also didn't need to lecture anyone like that on hacker news, thanks!
What they are asking would be used as an annoying tool against the user in the same way today sites ask for user location or push notification (on other OSs).
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.
lol, this was a project I did for a friendly event free of charge. I choose PWA because it's only useful for three days and nobody is going to install an app for this, you want it working right away. I was getting good results but the experience was just way smoother on android. A good prompt/banner/whatever that the app is installable felt essential when viewing the users behaviour because it's "drive-by" usage.
> 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.
On my phone, when I click "Add to Home Screen", it immediately focuses the name text field and pops up a keyboard. As a user installing an app, I expect to see the name, the icon, possibly a description, and a big, obvious "install" button. I do not expect to suddenly be presented with a keyboard letting me edit the name of the app. When a user changes the name, it is far more likely to be a mistake than an intentional action, unless the PWA did a phenomenally poor job of naming itself. On Windows, when you install an application, do you expect it to start by highlighting the app shortcut and entering edit mode so you can choose the name of the app? No, that would be bizarre, and it is bizarre here too.
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.
I honestly think you are overthinking this. Many users would actually prefer to customize the displayed name. Discoverability of the installation process is IMO the real issue.
Then why doesn’t iOS ask users to customize the displayed name of native App Store apps before installing them? As I said, I think it should be consistent, and I don’t think that's a hugely controversial opinion.
Also, why don’t Windows or Android ask you to name apps before you install them? Why doesn’t Steam? This is just not how installing apps works. At a minimum, I would like it to avoid popping the keyboard up by default. If a user wants to edit the name, tapping on the name themselves shouldn't be a problem.
> Discoverability of the installation process is IMO the real issue.
> On iOS, users have to click “share” and “add to Home Screen”
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 view Apples reluctance to implement the install prompt as politically driven. They want to favour their AppStore and make installing Web Apps unnecessarily hard.
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.
Actually not bad. We are converting all our native apps to either webapps (still available in the store) and as a PWA. Performance was always an issue, but nowadays we are convenient that performance is good enough. Developping in web is soo much easier, cheaper and much much faster.
Rather than a separate PWA "Add to Home" prompt, it would be nice if they added simple PWA support to the App Store directly. Microsoft's app store supports developers just dropping a URL to their web app manifest as pretty much the only thing needed to add a listing to the Store. (It also supports providing previous package IDs to migrate older apps to PWAs. Microsoft's Bing crawler will also sometimes pick up web app manifests and add basic listings in the app store when the manifest has enough information to do so.) Android app stores are in various stages of supporting similar things.
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 view Apples reluctance to implement the install prompt as politically driven
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).
There should absolutely never be a prompt to install PWAs.
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.
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
Good. Web push is such a mess. The amount of people with Android phones like my grandma that accepted push notifications on some spam site, either by accident or because users are so conditioned to just click "ok" to make popups go away, it's absurd.
The request mechanism is so broken. There shouldn't be a pop-up at all. The website should declare a notification source and you should be able to subscribe to it if you feel like it. Somewhere in the overflow menu. The website shouldn't even get the option to natively bother you about it.
I mean then they’d just have pop ups that told you how to turn on notifications and make it seem like you have to to continue… wouldn’t be as successful but it would still suck.
It would at least be harder. It's a lot easier to sell "click ok to make the pop-up go away" than "go into the overflow menu, then click 'subscribe to 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.
That's the right way to do it, but then the Chromium team that implemented it doesn't get good numbers to use for their promo packets.
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.
It's not just Web Push, most permissions should be user-prompted, not site-prompted.
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.
One of the things that excites me about Apple's approach here in particular is that it's very easy for people to understand: Users intuitively know they can install apps to do things on their device, and uninstalling the app will make those things go away/not happen. While still using web app technology, it embraces a much more classically understood concept. I hope the other browser companies follow suit.
The site permissions model feels more empowering and narrow-scoped to power users, but it's absolutely baffling to everyone else. Install and uninstalling is simple.
I kind of dislike the app/website distinction that people make sometimes, but even I feel like this is a pretty decent line between the two: "a thing I 'install' means that I want it to have more capabilities than something that I want to be transient." I agree, it's good UX.
And similarly, it's great to tie that to the app list -- it means if you want to get rid of those permissions, you now have a really easily viewable list of every site that's sending you notifications (I'm assuming that iOS revokes push notifications if an app is unpinned from the homescreen).
There are ways in browser to get lists of every site that can send you notifications, but nobody outside of tech circles will ever find them. In contrast, this is reusing the same UI that you'd use for any other cleanup action. Everything that can send notifications is in the same place. That's something I can explain to a non-technical user.
And yet they allow auto play. I wish they hid that behind a permission. It's god-aweful. Looking at you Ars Technica. Go burn someone else's mobile data.
It's wild to me that we all recognized autoplay was a problem, Google broke a bunch of websites, there was a big stink around it, and so 5 years later... we still haven't solved autoplay. Nothing has changed, we just stopped talking about it.
I made a demo showing how easy this was to circumvent in 2018 and it works just as well today in both Chrome and Firefox as it did in 2018, nothing has improved since then: https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying audio).
Right, that's the point. How often do you browse a web page and never click on anything or highlight any text? If you're interacting with a SPA like Twitter or Facebook, it's impossible for you not to have a user action by the time you run into a video. It's fairly common for web articles to put everything except the first two paragraphs behind a "click to expand" button. What that does is force you to invisibly give them permission to autoplay audio.
Chrome introduced a solution where in practice, videos still all autoplay (the demo doesn't show this, but if you start a video muted you're still allowed to autoplay it), and then 15 seconds into browsing the page you still get hit with a blast of music. And in the process of doing that, they also broke a substantial number of web games.
And, also, the restrictions don't apply if you're browsing within a domain, so if you click on a CNET article and then click a link to another CNET article, now the second article has permission to play even without a user gesture. "In response to a user gesture" is such a weak protection. Highlighting text counts as a user gesture.
My preference would have been for Chrome to just auto-mute that tab as soon as audio started playing, and allow the user to unmute it themselves not as a gesture that "implies" consent, but by explicitly clicking the unmute button.
I don't think the current solution solves anything at all, I think it's worse then what we started with. Particularly on mobile, it's extremely easy to accidentally tap on a website. In my opinion, it's effective the same thing as just allowing autoplaying audio, I feel like they might as well have changed nothing.
Edit: I've got a longer article I wrote in 2018 that goes into more problems, but a lot of them are orthogonal to the current conversation and are mostly focused on the impact to web games and criticizing Google's communication with developers, so I tend to just directly link to the demo when talking about it nowadays (https://danshumway.com/blog/chrome-autoplay/)
It's become really common on websites, and it's one of the primary reasons why I block JS by default on my phone. I assume a lot of mobile apps work the same way, but I haven't checked. I don't think you could pay me to install Instagram on my phone.
To be more specific about why the Chromium model is so messed up, it's based on the idea that you should only be able to start audio playback in response to a user action.
But what counts as a user action is:
- highlighting any text on the page
- clicking anywhere on the page
- pressing any key on the keyboard
- basically anything you do on a web page.
And then the web page can play any audio it wants for the entire duration of the page visit. So in practice, blocking autoplay only makes things more inconvenient to devs and breaks a bunch of websites. It doesn't help the user at all.
Firefox's implementation is slightly better because it's more predictable (Firefox doesn't have Chrome's weird algorithms about playback), but it's still mostly broken. I wrote a giant article about this back in 2018, and 5 years later the demo that I made works just as well today as it worked back then: https://danshumway.com/blog/chrome-autoplay/demo/ (link has autoplaying music)
Nothing ever got fixed, and autoplaying audio is still a problem.
Eh, in most cases it is just Chrome. WebUSB, Web Serial, a dozen others, Chrome has implemented despite both Mozilla and Apple saying they won't because the risk of malicious use is too high.
I would argue (and have argued before), if placed behind a well-understood consent concept like "installing" the PWA, it would be safer to implement these sorts of APIs.
FYI, you can disable the ability for Chromium-based browsers to even ask the user if they want to allow notifications - on my Android phone in Chrome, it's under Settings, Site settings. There you can set "Notifications" to "Blocked" (and if you're paranoid like me, turn most others off as well).
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.
Absolutely fair, but that's why I set that on all browsers I configure for family, and recently had to walk my sister through on her phone when she accidentally allowed notifications from some website that started spamming her with various scam attempts.
I don’t know if they’ll accept this solution.
The other camp just want: “It works automatically like magic”.
I just want to point out that we have to be familiar with the tools we used.
As I understand it (I never want notifications so don't have any experience with it), it's only blocking new sites from asking to send notifications. So if you find a site you want notifications from, you can change that back to "Ask" temporarily, allow for that site, and then change back to "Block" for all sites by default.
Note that that behavior might be different on mobile vs. desktop browsers, but again, I don't really know how to test, sorry.
Good question. I think the main difference is that it is so much easier to visit an annoying website then to download an annoying app. And your GP mentions how a good compromise is to grant this access only to websites you install to your home screen (which I think is a comparable action to downloading an app).
I regularly get spam notifications from major/famous iOS apps. It's always an instant uninstall for me.
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.
My parents are in the same boat. Revoking it assumes the user even has a mental model of what a notification is. That is: Something that you can opt out of or even necessarily that they gave permission in the first place. I suppose it's viewed a bit like receiving junk mail or advertisements on TV. That might seem absurd on the face of it like of course it's your device but not everyone is necessarily aware that they even have any agency (or are interested in learning yet more "computer nonsense")
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 parents are in the same boat. Revoking it assumes the user even has a mental model of what a notification is. That is: Something that you can opt out of or even necessarily that they gave permission in the first place.
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 might be misremembering, but I think android (at least Pixels) have a prompt to ask if you want to get rid of an app's notification if it pops up too often, and/or show you the current settings for the notification for review.
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.
Nobody who doesn't work in the industry knows how to do this. Browser site permissions are basically the absolutely most incomprehensible UI ever to ordinary users. It's why implementing these features without an app install is user hostile.
It's a good restriction although I wish Apple helped a bit with the installation of web apps to the home screen.
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.
For people who haven't used iOS, the Share screen is the ios junk draw where every option they couldn't find a better place to put something goes. Things like Find on page are located there too.
FYI you can just type in the address bar and a “find in page” option appears in the autocomplete list if that text is on the page, no need to use the share screen
The worst part of this is it’s the last item in the autocomplete list, and will often be under the keyboard, off screen until we scroll to it. It also hides the current page behind the list of course.
All in all, text selection and search is still such a second class experience on iOS.
Thanks, was going to answer the same: nor the "address" text field nor the "share" button indicate actions to be performed inside the page; the logical idea is that first one is to go to another site, the second one is to transfer the current page to another app/person
I have to admit I don't see where to put the "search inside the page" feature, definitely some ux trick to be found
I disagree, the “share screen” is the logical place for actions that operate on the object you’re currently looking at. Adding a new banner or something for installing PWAs would just clutter up the UI and make it less consistent.
Somewhat off-topic but as someone who used to be a very heavy iPad user (the M1 Mac has kind of obsoleted it), I think of the share sheet as the equivalent of a Unix pipe. It takes your current view or output and makes it available to another process - and if you use Shortcuts, you can actually see the data and its transformations along a literal pipeline.
So, back on-topic, it does kind of make sense in that you’re taking the current URL and sending it to the Springboard.
A perfect menu already exists for this. If you click the “Aa <puzzle piece” button, a bunch of website-specific settings pop up. “Search on Page” or “Install on Homescreen” would fit in perfectly here. Maybe under “Translate Page”.
This is close, but it’s not ideal: the drawer is an OS-wide feature, that puzzle menu is a relic of when the drawer didn’t exist. And its symbol suggests that it’s about text options.
You’re not wrong, however they’ve actually been cutting down on that lately — moving the items which aren’t really “sharing” in any sense to a kebab / ellipsis.
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.
"Share sheet" is a bit historical in my opinion, and has been for some time. In practice it serves as more of an OS-level context menu that happens to put the "send to frequent contacts" and "open in another app" options first.
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.
I don't think there is a limit to how many apps icons can be in an iOS folder, they're paginated. Right now, I have 27 in an "Apple" folder, spread over 3 pages. If I add another icon, it adds another page.
It could, but I won't hold my breath. I've fallen into the trap of being optimistic that some annoyance will be fixed or some obvious improvement will be implemented in iOS <next_version> multiple times and ending up disappointed. I'm even less hopeful of anything that would improve PWAs, whether in terms of API support or user experience, due to Apple's incentive to keep them second-class.
Oh thank god. I was worried it'd let sites ask without the user first taking some action to permit it. Sites being able to pop "allow notifications?" without the user first indicating they might want that, on desktop, is a menace.
My mother has an Android phone, and she’s not really tech savvy. Her notifications are absolutely bombarded with garbage from various websites, and her lock screen displays ads. I’m moving her to iOS, as I’m quite sick of constantly being the IT guy.
Desktop browsers don't have this limitation and I never have to play that game. It's just a stetting where you can choose to allow websites to ask for notification permission, or block it from every website.
Part of the problem for desktop browsers (except for power users) is that they've never opened the settings option, not once. They might have opened Mac's system preferences or Windows Settings app but other than that they have no idea they can toggle a plethora of options for their browser.
Check in with the average user of desktop browsers. You may find a lot of them have accidentally accepted web pushes and have no idea how to make them go away.
I'd be shocked if the vast majority of "use" of the "feature" weren't exactly that kind of spammy, unwanted messaging.
I dislike the desktop implementation of push permission request in macOS Safari
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
My desktop browsers get denied permission to show notifications at the OS level and are set to block them for all sites without asking.
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.
Ya. It's safe to assume if someone is opting to add a website to their homescreen they are interested in it; notifications may make sense. Random websites asking me to enable desktop notifications are annoying. This prevents that for mobile.
I agree. None of this stuff should even be requested before the user makes it clear they are actually interested.
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.
I guess websites will start asking users to add them "to the home screen", so they can later start asking permissions for push notifications...
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.
It's actually pretty difficult to do something like that since an install is done through the OS and the app can't set off the process. I think it's too clumsy for most sites to try it.
I'd have expected no less, since Chrome already protects the notification noise by default, too. You have to opt in to notifications. Sounds like a slightly different implementation for iOS, which is interesting in that they're assuming any app you add to Home Screen means your opting in to the notifications, or is there another opt-in? I see myself putting a few apps on my home screen that I want to click on often, but maybe not wanting the notifications to go with it?
A web app that has been added to the Home Screen can request permission to receive push notifications as long as that request is in response to direct user interaction -- such as tapping on a ‘subscribe’ button provided by the web app. iOS or iPadOS will prompt the user to give the web app permission to send notifications. The user can then manage those permissions per web app in Notifications Settings -- just like any other app on iPhone and iPad.
> Chrome already protects the notification noise by default
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.
I get asked, but once I say no, I haven't gotten prompted again.
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?
I believe adding a site to your home screen isn't opting in to notifications, but opting in to allowing the site to request notifications, which would then require another opt-in.
This seems very unintuitive though. Why not just add a button somewhere that says "enable notifications"? Apple loves these super unintuitive approaches. Blows my mind that anyone actually believes the marketing that they're "easier to use" than any other platform.
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
> Added WebRTC support for hardware AV1 decoding on supported device configurations.
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.
They may still be able to offer optimized decoding with hardware support on older devices. Not a full hardware path but a very well optimized CPU + hardware combo.
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.
Good news! You'll only get notifications if you save a web app to your homscreen and then explicitly give it permission. And then you can choose to limit it to only badging, as with native iOS apps. Or you can use focus modes to manage which notifications you can get in different situations, as with native iOS apps. We've been careful to minimize the risk of notification overload as much as we can.
I'm glad that there's controls in place to help minimize the issue, but I also know that companies do a good job of making people think that they need to enable settings on their phones that they don't.
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 completely agree about notification spam being an issue, but why should native apps get a head start over PWAs here?
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!).
> I completely agree about notification spam being an issue, but why should native apps get a head start over PWAs here?
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.
However with a native app, you've chosen to install it, so you're at least partially interested in its notifications. With a website, you may just have browsed to it and have no intention of ever returning again. So the point of having to "install" the PWA to your home-screen mimics that first stage of intention.
The key issue (as many others have noted) is that the "installation" step is still somewhat arcane.
The difference is that Apple has rules about what can going into App notifications, and if developers don't follow the rules they can kick the app out of the App Store. (Not saying they couldn't be better about this, but it's at least an option even if it's not perfect.) But they'll have no control over what notifications from web pages you've put on your home screen show. It will make notifications a worse experience for users all around.
Apple has rules surrounding using push notifications for marketing uses, yes. They haven’t enforced them for a decade. Apple’s own apps are guilty of blatant rule violations. Not to say that there’s any expectation that Apple would follow their own rules. Rather that the company doesn’t see the value in following them. So. In the hypothetical universe where they still cared, sure. But we aren’t in that universe.
> The difference is that Apple has rules about what can going into App notifications,
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.
I'm like you I disable almost all notifications by default. For some pesky apps that try to be cheeky about it, like Uber Eats requiring notifications but then not letting you opt out of promotional ones, I turn them on only for the duration of my order.
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.
> 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.
Unfortunately, not schedulable as far as I know, the notification needs to be sent while the web worker is running. Again, I'd very much love be wrong about that, but I don't think there is any way for, just as an example, a habit tracking PWA to say "ask the user at 10:00AM every day if they've gone for a morning bike ride."
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.
I don't know how fine grained you want your notifications to be, but you can get pretty far without storing user data by splitting notifications by topic on the queue, or by filtering client-side in the service worker itself.
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.
> 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
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.
You don't need an account and you can encrypt the message before queuing it on the server. Silly stupidity inefficient and won't work offline but it is quite easy to make a generic push message scheduling server that just pushes around blobs as requested by client-side code.
That's an interesting point. It's still pretty messy and inefficient, but you're right, you could at least get away with not exposing user data, even if you're still transmitting it around.
That's a good suggestion, I should play around with that some time.
Am I missing something? Firestore is an online database that requires setting up a Google account. It's sort of like responding to "I wish I didn't need to include a serverside component" with "Linode".
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.
I don't get why apple does not take a similiar path on mac. Some websites are really apps for me (stuff like overleaf). I would gladly add them as apps and use this to unlock all those advanced functionality. But so far, at least on safari for mac, all those web-push websites are mostly spam. I only have a few where it is useful but I use them, again, like normal apps, and would be fine of adding them to my library.
Nobody uses the mac app-store anyway, so why bother? Why not do it?
Sounds like this is the motivation Apple needs to bring their notification-handling into the next century. I'd love for Apple to give me a way to disable "Try the New Safari!" notifications without opening my terminal.
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.
Something which developers have widely refused to embrace despite being pushed by Steve Jobs himself during the iPhone keynote.
Yet somehow it's always Apple holding it back with their magical minority market share.
People have forgotten what a big deal that keynote was and what it meant for the mobile web. Go back and pay attention to the “desktop class web browser” stuff. Apple almost singlehandedly changed the mobile web from something almost nobody wanted, into something actually useful and mainstream. And Steve Jobs was there right from the start telling everybody if they wanted to build applications for the iPhone, they should be mobile web applications. It was everybody else demanding that iPhone applications be native, not web-based.
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.
There have certainly been functions that were necessary for some kinds of apps, but there are possibilities for kinds of PWAs that would have worked for years on iOS (and Android/desktop) but they barely exist if at all.
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.
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.
> 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.
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.
They don’t need to know. They just need to click on the banner which will be on every Google search result pages. How do you think Chrome got its market share on the desktop?
In general yes, but web push is kind of the exception there because this API needs OS level support to wake up apps. Switching to a blink based browser would not help with that.
Why not? If you run Chrome (or Firefox) on iOS, can't the app ask for notification access using the normal OS API? It will then "lend" this functionality to websites, so that when they have an update you'll get a notification from Chrome saying "Website X: Hello world".
That'd require a whole other push system operating on top of the normal iOS push system. Web app users would have to go through some Google-hosted push clearinghouse that wrapped some new format within the existing Apple push protocol, and it'd only work for Chrome.
[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.
Isn't this literally how it's done with every browser on earth? I'm using Linux. Websites don't use DBus and notify-send, they use native Web APIs to talk with the browser. The browser then uses the OS notifications API to translate them, and yes, it manages all the subscriptions too.
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.
Freely accessible as in not vetted by Apple. No approval process, no need to pay $100/year, no need to buy a Mac. (Also, gone would be the 30% Apple tax on "in-app" payments.)
You'll need an app-specific cryptographic key to connect to the push service, unless that's changed. And you'll need some system for registering and de-registering push tokens (unless that's also changed).
> because we can't just use the web browser already installed
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!
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.)
Your service worker dictates what the browser should cache. You could cache static assets only and let the browser hit the server for document requests.
As for the refresh button, mobile users are now used to pull to refresh so you might not need an actual refresh button.
As an aside, I dig the design! It reminds of teletext haha
It has been awhile since I've personally tried creating a PWA, but I don't think iOS does any form of extra caching for PWAs. I think it is more likely that you copy/pasted an example service worker that was caching things you didn't expect it to cache. Some info about PWA caching here[0].
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.
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.
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.
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.
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.
The instructions to install vary by device, OS version, etc. etc.
It should just be equivalent to native apps. A link to an App Store URL takes the user directly to an install screen. It was clearly seen as enough of an issue that they implemented that, so there's no reason web apps can't be the same.
If you think the bulk of users even know what "share icon" is you're kidding yourself. If you think they find that modal window intuitive you're kidding yourself. Even then, you're sharing... to the home screen? "Share to the Home Screen" is not the way anyone thinks about installing an app. The whole concept is a mess.
So you’re saying that you’d like to send web notifications to users who aren’t “technical enough” to add a website to their home screen? Surely then they are also not technical enough to unsubscribe from these spammy popups. I am glad that Apple protects my mom from this nightmare.
That's what I'm saying about device variation: that downward pointing arrow would be incorrect on an iPad because the share button is in the top right. Exactly how far from the right depends on OS version, whether the screen is portrait or landscape, whether you have a larger text size enabled in accessibility settings...
And _all_ of this is ignoring the fact that Android also exists. Half the point of using the web is to be able to do stuff cross platform, once you start sniffing user agents and screen dimensions you're creating something doomed to fail in the long term.
I don’t think anyone cares, no, because to them it’s a meaningless technical distinction.
They shouldn’t have to care. I think they want to install an app. If it were equivalently easy to install a webapp vs native most users would be happy with either. But native is a two-tap process, web is a mess.
In Apple parlance I believe they call it the action button not the share button. If understood that way adding to Home Screen is easy to find. The fact that so many people on HN keep calling it the share button means that Apple hasn’t communicated the concept very well.
I Google "ios action button" and find nothing. I google "ios share button" and screens full of the button we're talking about. So regardless of "Apple parlance", this is the "share button".
It's not intuitive and most users won't find it.
I honestly didn't think Apple wanted the web to succeed, so I was surprised when Jen Simmons joined but it seems like she's moving the needle!.
Absolutely, yes - and this is a great example of how out of touch most software-experienced people are with how stupendously confusing/non-discoverable most UI is for most users.
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!
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.
Sadly I don’t think it will change anything. It’s different from Chrome so it lacks the feature of the week and needs “special fixes” because it has a different rendering engine.
It seems to be doomed to persona-non-grata for a lot of developers. At least until the Chrome worship dies.
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?
> In iOS and iPadOS 16.4 beta 1, third-party browsers can now offer their users the ability to add websites and web apps to the Home Screen from the Share menu.
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.
At this moment of time, there aren’t any non-WebKit browsers available in the App Store, so “third-party browsers” in this context means “WebKit browsers”.
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?
You can rent virtual/remote iOS devices. Those are the only realistic alternative I know of and you'll probably need to expose your dev server to the internet somehow for it to work.
There are also open source webkit builds like GNOME Web (though they're quite different from Safari in many ways).
> 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?
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.
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.
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
AFAIK notifications should come in as long as Chrome's daemon is running. This should run on boot, unless Chrome has been manually force killed, or if Chrome has crashed.
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 think something funky is going on on your device. Maybe Chrome or one of its tabs are running into some kind of memory leak? Maybe the OS is failing to kill enough other running applications and is letting Chrome hit some kind of memory limit? Maybe there's a bug in Chrome on certain devices?
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).
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.
Ah, I was waiting for the first goalpost shifting comment. I had to scroll uncharacteristically far for an Apple thread to find one, and you’re the lucky first!
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).
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.
Finally! Can’t be more excited if not that it’s super hard for the common user to add web apps to their homescreen. I’m against an install prompt api, the web is already a shit show of banners, like other commenters pointed out. But something like a little badge on the address bar that once tapped tells you the web app is installable would be great imo
By looking at App Store and Google Play policies, reviews* and putting the big companies at the storefront, PWA should become the default. It can also minimize planned obsolescence (as long as CA certs are valid).
*Not to be confused with users' ratings and reviews
Does anyone know if this release includes universal link support?
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?
Compared to other OSes people update iPhones really fast. Apple really encourages updates (new emojis!), including automatically updating things unless you stop it.
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.
But please no demos from other code forges, blogs, the spec, or the web in general? Code exists everywhere. Git is distributed version control—not centralizing code a feature. You didn't need to specify a specific place.
But feeding into a proprietary product isn’t good for us. Using Google and Photoshop as verbs isn’t great as is, but Git by its nature as a DVCS it becomes even more important we don’t have our language drift in a way that centralizes. Specifying that it is Git is even of questionable value.
“Are there any samples with the source available“ is a better phrasing (minimal and self-contained aren't implied by naming a platform).
Web Bluetooth is not a web standard. It’s something Google implemented by themselves that no other rendering engine wants to adopt. Both Firefox and Apple have explicitly rejected it.
Native Chrome is coming to iOS. Soon enough you'll be able to show users screens like "your browser is not supported, upgrade to iOS 16 and download Chrome" if you want to use Chrome exclusive features like those.
Even if/when we get the Blink rendering engine in iOS Chrome, I think Apple will still prohibit access to certain features like Bluetooth if they consider it a security or privacy threat. Are Web Bluetooth, Web USB etc. even considered part of Blink, or are they part of Chromium?
I doubt the legislators that are forcing Apple to open up the browser engine market will be very happy with Chrome being refused Bluetooth access for use in practical, real-world features.
As far as I can tell, these APIs are part of Blink. Even if they're not, Chrome/ium will be ported to iOS eventually.
Unless I’ve misunderstood, this a quite a big event in the history of the web platform. Apple’s quiet refusal to support this part of the PWA standard has for years been quietly maintaining a significant situation: that if you wanted to make a viable digital product that involved notifications, you basically had no choice but to make a dedicated iOS app, along with either a PWA or an Android app. If iOS Safari fully supports PWA notifications, with no funny business, that is no longer the case. Suddenly it is viable to make a single version of your app for every phone.
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.
Isn’t there a push by some legislators in some countries for Apple to allow alternative app stores on iOS devices in the near future? That might have something to do with this perhaps ...
Exactly, I think that's what this is about. either no need to allow sideloading cause PWAs, or it's an olive branch to iterate closer to prevent the big hammer from dropping. Also of course possible that Apple just supports it, but given then long history of evidence against that I don't consider it likely.
> This also has big implications for the hegemony of the App Store and Apple’s control over the web platform
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.
> And they never took off not because it lacks push notifications or some other minor feature.
Actually, that is precisely why they didn't take off: Without push notifications a lot of mobile applications are simply not feasible. If something is not feasible, most people will have no reason to invest in ux. It's self-fulfilling.
However, with push api, cache api, being installable (and maybe some additional apis that elude me right now), I don't see any specific thing that would not allow carefully crated web apps to have great ux on mobile.
Download the Twitter and PWA apps. Compare the two.
If you think the only difference between them is push notifications and one click install then of course you will think PWA will be a success. But a lot of us can easily see the difference.
And based on the last 15 years of real world experience there are enough users like us to sink the hopes of PWA apps.
When you have a strong reason to not optimize one of two ways of building your mobile app, you are not going to optimize one of two ways of building your mobile app. Not having push notifications – for years on end, with no inkling if that might ever change, because the platform makers have strong reason to sabotage it – is a pretty strong reason, specially when your measure of success is literally how often users get distracted pulled into your app.
In 2023 there is absolutely nothing that would technically not allow us to build a buttery smooth 90fps experience in any mobile browser running on a recent-ish phone. Of course that is not to say it's particularly easy. But then again, so isn't building a performant native app.
The twitter PWA is actually a very good PWA. But it doesn't implement some gestures like swiping left to see more feeds on the home screen, and has little to no animation support (retweet dialog pops up, instead of animating in like it does in the native app). It also does not do paint holding, so you get a temporary white screen when swiping back to the previous screen. But all of those problems could be fixed, with current web tech, afaict.
Is there any other lackings (which might be fundamental and unfixable for a PWA) that you had in mind?
I am genuinely curious about this. I prefer native apps to web apps, but I have notifications disabled for every app I install except those that my wife and parents use to contact me. I’m sure I’m not alone in this behaviour - I hate notifications and any workflow model based around them.
Is my viewpoint very uncommon? Are notifications generally used and loved by users? Do app developers have good stats about this?
Thinking as a fellow notification disabler, and having no data, just intuition:
People want their attention to be tapped. I am not exactly sure why that is (although I am sure that it can't be good) but notifications are a tap on peoples attention.
Building certain apps without notifications seems like it would simply not be acceptable to must users. Most phone apps still vibrate or ring – that's basically a notification. I would go as far as saying its uniquely distracting notification is the primary feature of the phone app but, at the very least, a phone without one would be something very different. And since messengers basically compete with phone apps now, for most people that would probably not work.
It's not an uncommon viewpoint. But the fact of the matter is that without notifications it is hard to build a habitual trigger loop to re-engage users (a lot of things just fall out of mind and sometimes you'd like a reminder or a notification of something special). If you are careful with what type of, how many, and how you send notifications, then not as many users will disable them.
Yes absolutely. People will learn a new way of interacting with webapps. Currently nobody installs a pwa. But maybe that'll change. Going through the web browser is inconvenient for some apps (unnecessary extra menu on top). After installing however, the experience is very similar.
I once made a chat app that had significant traction on Android, and many users wanted to try it on iPhone but there was no way to do so without web push, and it was fundamentally banned by the app store guidelines and without side load there were no alternatives. This is a game changer for those kinds of apps!
I don't know what the percentage of "native" apps that are really web views and/or javascript underneath, but am certain that it's a lot. In fact, I wouldn't be surprised if it's more than 50%.
Is isn't noticeable at all if the app is built correctly. My app is used by health care professionals to log their hours and patient charting. Everything is instant when clicked and the app also has limited offline functionality. It's snappier than most mainstream native apps. Everything is native HTML 5 & CSS with very minimal javascript to handle logic and validate inputs.
> I assume you have a native app as well and have benchmarked both with users.
Yes, I can speak for them. They compared their native implementation with the one that exists. The users enjoy using the web app compared to the current native app.
Why? Because it doesn't exist. Because creating a native app doesn't solve the problem. Because when you say "native", do you mean iOS or Android? Or Mac? Or Windows? Or Linux? Or whatever else there is?
Yes, eventually, there might be a desire to build out a native app if it's needed. But the assumption that everyone needs a native app is absurd. Not everything needs a native app, and can work just fine without.
As for this persons users? Yes, they enjoy the PWA, because without it, the "native" app wouldn't work for some of them.
If it’s a choice between PWA and no app then of course PWA has a use.
But if you think it will upend the industry then that is frankly delusional. PWA apps are worse than native in every single way for the user. Great for developers. Terrible for users.
Developers trying to satisfy their users are not trying to upend the industry.
And as users can't tell, why is it terrible for users? All kinds of apps can suck and be user unfriendly. That's a different dimension than native vs web.
No work webkit does on PWA-like features matter for as long as the install journey is as intentionally user-hostile and non-discoverable as it currently is.
For the record, on Android it's also shitty, but not this shitty.
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.
What are the anti-abuse features built into this? Can Apple disable push notifications if the website gets hacked and is actively stealing people's info?
> Can Apple disable push notifications if the website [] and is actively []
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.
On iOS you get asked the first time an app tries to show you notifications and it's very easy to disable them after the fact too. Since PWAs are just apps you add to your homescreen nothing will change in this regard.
As an aside, how would a notification steal your info?
This is not a threat model that's unique to PWAs though, nor in any way enabled by what's seen here. Installing a PWA is practically equivalent to installing an app and a malicious app or an app that had their OneSignal or similar credentials compromised could do the exact same thing.
I think this is a good step. However, there is still many things that Apple can implement easily to show that they care about Web Apps. One simple example is that you cannot lock the rotation of a Web App like a regular app. There is plenty of stuff like this that would make Web Apps feel native. I hope they improve upon these things.
I strongly dislike this. My grandparents are on Android and they are driven mad by every site pushing them notifications, 24/7. We're talking about non-tech people, 70+ years old. I ended up turning off notifications for them altogether because I couldn't find a fix. On iOS this is easy, Safari won't have access to notifications on my phone.
You have to add the web app to the home screen, then the app needs to ask permission on a click event, the user needs to grant the permission and then focus mode, etc can still filter them out.
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.
With the (controversial) incentive for Apple to move away from PWA's and toward native apps, this has to be welcome news and useful for developers and consumers alike. Their fine balance between being anti-competitive and providing just enough tools to keep users from switching to Android continues.
Their previously leaked internal debates about openness and iMessage for Android in particular is fascinating. Would love to see it on this topic.
Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?