Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> I also believe that a lot of APIs in iOS are not available from PWAs.

The security model of a store is delegated trust and stewardship. There is someone who will review if applications need capabilities, and will provide business penalties for bad behaviors.

The security model of the web is basically a mix of site sandboxing and caveat emptor. There is no guarantee the web app you hit one minute to the next will be the same code base, or belong to the same owner. For example, the same interface has to get consent for notifications from an advertising site which wants to spam you as your corporate chat app.

Chrome had quite a bit more motivation to ignore this or to create a tiered model with PWAs because of Chromebooks, where the model (originally) was web-only development. Google created quite a few one-off API for their systems, and promoted several Chrome-only API as if they were web standards. Even there, this approach was too limiting and eventually Android compatibility was added.

Apple has started to add some additional app-useful features like notifications, but behind the 'Add to Home Screen' option. One could look at this like promoting a website to an 'app' on the phone, partially because that gives a consistent way for the user to understand permissions and privacy implications for both native and web code.

There are plenty of people who wish there was a better mechanism on iOS than the current add to Home Screen flow, but it is highly unlikely to become more streamlined because of abuse potential.



Meanwhile, these "trusted apps" are regularly executing whatever code shows up from server-side.


To be blunt, and clearer: Apple's reason, your reason, for them being hostile towards webapps is unconvincing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: