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.
Keep it user-driven.