Hacker News Reader

Comment by cageface | Hacker News Reader

iOS safari users have made up at least 50% the traffic of the last few sites I’ve launched. In the US at least they effectively have veto power on new browser features.

View on HN

They haven’t vetoed any features. Google added a lot of features without implementation (and security) in mind. The last parts of “PWA” are its most vulnerable, and with apple having such small safari team, they don’t have the same capacity to help google do it’s job, since they rushed all the features without presenting to W3C.

Push notifications are the most obvious example of a feature webapps need to compete with native apps that Apple has so far refused to implement on iOS. They’re also much aggressive about wiping out local storage data.

Whether you agree with these decisions or not Apple is clearly and deliberately using its influence to limit what a web app can do.

Apple is clearly and deliberately using its influence to limit what a web app can do, in many cases to protect users against features that are poorly designed and harmful to privacy.

I don't see how supporting push notifications for native apps is any different than PWAs. The user would still have to explicitly enable them for the installed PWA, and could revoke it at anytime. Safari for desktop actually supports push notifications [0]. So why not mobile Safari? Even the their aggressive deletion of local storage could be handled with a permission request. Once you've installed the PWA it could ask the user to store data for longer. Basically what I'm getting at is that Apple already has a robust permissions system that could easily be extended to support PWAs and the necessary features, but they seem to choose not to do so.

[0] https://developer.apple.com/notifications/safari-push-notifi...

Push notifications are just one example. Bluetooth is another - which clearly has privacy issues.

As to why not mobile Safari, perhaps Apple doesn’t want to be tied to limitations of the design?

Apple’s push notifications on mobile have evolved significantly over time.

Just because they could do something, doesn’t mean it is a good design.

Bluetooth does have privacy issues, but again, that's no different than a native app. If I install a native app, it doesn't get free reign over BT or any other device feature. In order to use any hardware feature a native app has to request permission to use it. I don't understand how a web app is any different in that regard. A PWA could specify the features it wants to use in the manifest.json just like a native app does with the Info.plist. Then iOS could prompt the user in the exact same way. If the iOS permission system isn't a good design (I think it is) then why do they keep using it and expanding it for native apps but not use it for PWAs.

Apple has the ability to remove apps which abuse their permission requests, e.g. by lying to the user about what they are going to use the permission for.

Not so with websites. The bar for including new functionality in browsers is way higher than it is for native apis because there is no way to police abuse.

There's nothing stopping apple from blocking app installs from specific domains/subdomains.

Blocking on a per-domain basis is nothing short of an eternal game of cat and mouse.

Reply on news.ycombinator.com