> 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.