Edit: It's been three years since I have last dabbled with PWAs. What has been the recent experience?
Keep it user-driven.
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.
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.
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.
> 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 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.
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.
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.
IIRC (and I may be mis-remembering) they mostly just added that in the first place because sites were hacking in their own (which, on its own, might be fine), and other sites were abusing that dynamic for phishing or otherwise scummy purposes (not fine), since there was no standard look & behavior for those prompts. As long as installing PWAs requires user initiation with actions in the browser chrome, and can't be initiated by a link in site content, that shouldn't be a problem with PWAs.
And that’s all anyone is asking for, which would make PWAs equal to native apps in that regard.
Your fervent opposition higher in the thread seems like a different position.
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.
AFAIK, such prompts are regular HTML with links to the AppStore. If so, how do you suggest Apple make it impossible to add those to a site?
The ones under discussion are not: https://developer.apple.com/documentation/webkit/promoting_a...
Apple controls the experience. The developer just tells Apple which AppID is connected to this website, and Apple chooses how to present this information.
Smart App Banners also react to whether the app is currently installed or not, which random websites obviously should not be able to determine for privacy reasons.
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.
If PWAs weren‘t arbitrarily restricted there’d be no reason to link to the app store because…you’re already in the app.
Spamming users to hit the install button would be like spamming users to bookmark your website. That doesn’t seem to be a problem (though that’s probably because people don’t keep their bookmarks on their home screen)
Now there are a couple nice things:
- if an app is not installed you can dismiss for a particular site and you will never see it again. The website has no way to trigger it, the API is more like “Hey Safari I have an app” than “trigger a prompt”. - unfortunately if the app is installed you can’t dismiss the notification to open in the app. This I quite dislike because many sites have certain pages on their site with no equivalent in the app. Sometimes I have an app and just want to visit the site without being nagged.
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.
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.
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.
> 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.
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!
But yes, Focus Modes definitely elevates it to another level when you've got Mode-specific pages.
I's long overdue to have them treated as first-class apps, though (i.e. allowing having them only in the app library and treating the home screen as an optional short cut only)!
While Apple don't invest in PWA, PWA is doomed from a commercial point of view.
It is a really sad situation because the user experience of PWA is match better than installing apps from the store (with higher install rate than native).
Twitter is (or was) one of those examples. It took months until I realize that I was using a PWA than a native app.
Something is very wrong if you can't tell the difference. The difference is night and day on iOS.
PWA app has significantly lower responsiveness, constant mis-touches on buttons, loading screens for every click etc.
That's certainly not inherent to every PWA, e.g. there is no need to have a "loading screen for every click".
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.
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.
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?
Once to get to app store
Once to click install
A double tap to verify after face/touch/passcode on ios
(I use iOS.)
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.
I can't believe people keep saying this with a straight face. It's as if they've never seen an proper native app before (any of the third-party clients to Twitter come to mind before they were axed). Or haven't seen actual good fast implementations like the one Twitter actually bought and surprisingly still kinda maintains (see on desktop, https://tweetdeck.twitter.com/)
Websites are not randomly asking for mic or camera because that would be creepy and visitors would just run away.
I am not lecturing, I am giving my feedback on the matter, like everyone else here. If your product is good, users will save your site in their home, don’t worry about that.
I thought it was fairly straightforward to add an "add to home screen" overlay to a webpage with javascript.
On Android, yes. On iOS, users have to click “share” and “add to Home Screen”, which practically nobody knows how to do, and it presents the user with a rather confusing prompt for them to choose the name of the PWA they’re about to install. The website could tell you to do that, of course, but then it only works in safari at the moment, and it is very clunky.
iOS allows websites to show a banner that will help them install the equivalent app from the App Store, but there is no similar functionality for PWAs.
Some people speculate that Apple relies on the PWA install process being confusing to help push developers into the App Store.
Regardless of it being auto-populated, I think being immediately presented with the option to choose the name will inevitably confuse many users. If the user accidentally hits any keys, that will mess up the name... then they have to try to fix it themselves, if they even notice before they hit the "add" button. That just doesn't seem like a great user experience.
Talking about the "add" button, it is not called "install", unfortunately. The "add" button by itself may confuse users into wondering if they clicked bookmark by mistake. In fact, the interface is nearly identical to the bookmark interface in Safari, except that the bookmark interface uses the word "save" instead of "add", and the bookmark interface shows you which folder you're saving into. How clear and simple!
The "add" button is also a small button in the top right, which is completely different from how the "GET" button with a vivid blue background is presented in the App Store. Renaming and restyling the button to match the one in the App Store would make the experience more consistent for the user.
None of this matters to technical users like us either way, but making PWAs more accessible to all users requires making the process as easy as possible, smoothing out weird rough edges like this. The option to edit the name would make more sense under the Settings app or maybe an additional "Edit" option in "jiggle mode" on the home screen, if it should even exist at all. I can't edit the name of other apps on my phone. From a technical perspective, someone might ask "why can't I edit those names too?" But, it should be consistent either way, in my opinion.
Those are my opinions on the current interface, anyways. I don't think Apple has meaningfully changed it for over a decade, and if they have decided to care about PWAs, they really should polish this interface up.
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.
I agree this is certainly the biggest issue.
Thanks very much for your detailed explanation. Man, more and more I don't know how people can continue to praise Apple for better usability. So much shit on an iPhone these days is in completely hidden, non-obvious gestures or swipes - e.g. why TF would anyone think "add to home screen" would be in the share menu?
I keep seeing this touted as fact, yet no one has ever provided any evidence. I have the feeling everyone who says it is just mad at the feature not being there and they ascribe to Apple the most damming justification they can come up with.
Apple is greedy, especially under Tim Cook, but that doesn’t mean every decision is primarily motivated by it. Sometimes the people at Apple truly believe something is the right choice for the majority of users. Maybe you’ve been lucky to have never seen a relative’s device full of spammy web push notifications they don’t know how to turn off, but that is not rare. You can find reports of it among the other comments.
It would great if Apple similarly supported PWAs as first-class citizens in the App Store. It would also make a lot of sense: it would still favor the App Store as the "primary" or "best" way to install apps, and users would keep a lot of familiar experiences in choosing to "install" apps (much more familiar than Share > Add to Home, as other comments around here point out). Apple can even still try to curate the listings to keep them looking nice and staying informative (and whatever quality insurance checks they like to run). The users don't need to know or care that an "app" in the App Store is a PWA or not. Same with all the normal "Install Our App" and "Find this App in the App Store" links and prompts and modals (and "paywalls") those can/should all be the same experience whether the app itself is powered by Swift (or anything else) or powered by a PWA. Users that install PWAs via an App Store think they are still sommewhat locked into that app store's moat because they still think of that app as originating from that App Store. It's something of a win-win for Apple, I feel.
Not as a replacement for a general option like Share > Add to Home, because there will always be PWAs with no interest in submitting things to App Stores (and users will always want nice home screen bookmarks even for non-PWAs), but as a way to unify the install experiences for PWAs that do care about install metrics and app-like branding the best thing Apple could do (both for users and themselves) would likely be to allow developers to just submit their web app manifest URLs as the only "application code" in an App Store listing.
I agree. See also: the way you can't directly open an HTML document from Files (you essentially get a blank screen, even if all the JS and CSS is located in the HTML file).
If the site wants to tell me I can install the PWA by adding it to my home screen and remind me how to do so, it's welcome to, but no unwanted popups/prompts.