> Yeah, that’s the perfect web app, and we already have these in iPhone.

> [...]

> What I wouldn’t like for battery and privacy is if a web app could have _background_ activity — sending data to its servers, having access to mic/camera/sensors, running JavaScript spaghetti non-stop when I am not having the thing in the foreground.

This doesn’t make any sense. It’s just fear mongering at this point. It’s not “the perfect web app” that doesn’t do these things. Apple rigidly enforces privacy on web apps.

First, Apple allows you to control which sensors a web app has access to exactly the same as any app. They don’t just get to steal camera access for fun. This is the same privacy-first approach that applies to native apps.

Second, Apple doesn’t allow these web apps to run in the background period. They run when you have them open, and that’s it.

If Apple allowed PWAs to run in the background, you would certainly be given options to control that behavior. The way Apple does things, any background behaviors would likely be severely restricted in how much CPU time they get to avoid impacting battery life. But for now, the impact is zero, unlike native apps.

> native apps are reviewed by an authority I trust, upon every app update

It has been shown repeatedly over the years that native apps will often get App Store guideline violations past review by simply feature flagging such unapproved behaviors until after review. Apple seemingly can’t catch every example of this, especially among smaller apps, as they simply don’t have the resources.

Safari is built around a model of extreme distrust, since you’re browsing websites that haven’t ever been reviewed, and PWAs are isolated to another level. Native apps are built on a trust model that is slowly being reclaimed for minimal trust, which just means they’re slowly catching up to PWAs. Safari isn’t leaning on some human app review process to determine how trustworthy code is.

PWAs are more private than native apps. That’s just the reality of it, but Apple has nothing to gain financially from emphasizing that to their customers.

> native apps are also mostly native code, so they are easier on the battery without sacrificing responsiveness.

Swift and Objective C are surprisingly slow languages in most benchmarks, and mainstream JavaScript interpreters are mind-blowingly good. I disagree with your point here, this is really just a coin toss. Developers can write bad code for either platform, period, and a JIT language like JavaScript can often figure out which code is performing poorly as it is running and optimize it into better code. If people were commonly writing their iOS apps in Rust, I would probably find this to be a more compelling point.

In summary, I don’t think you provided any concrete examples of things that currently make PWAs worse than native apps. You’re just afraid of how bad things could be if Apple decided to stop caring and remove privacy and behavioral restrictions from web apps entirely, which is something they have shown no interest in doing.

No one is asking for web apps to just run amok. Apple should give the user the option to let web apps added to the Home Screen send notifications, exactly the same as any native app. I think it would be great if Apple could devise a limited background permission that PWAs could request, instead of zero background ability. Native apps have lots of legitimate excuses to run in the background far more than you might expect, and it annoys me how even turning off Background App Refresh doesn’t stop native apps from running in the background. Native apps that choose to violate App Store guidelines can run without limit in the background, and you’re expecting Apple to find and discover every violation by hand.

Also, HN isn’t a PWA. It’s just a Safari bookmark on the home screen, if you add it there. I don’t know if Grafana offers a proper PWA experience or not. Twitter offers a real PWA, as an example.