Hacker News Reader

Comment by alpacaillama | Hacker News Reader

Also interesting to note, that some of those APIs are still in W3C drafts. So Chrome just went ahead and wrote its own implementation without the literal standards body agreeing or disagreeing on them. Again, this author is extremely biased and I don't think this article is an informative take for anyone.

View on HN

I don't know -- this write-up and visualization completely aligns with my experience building mobile web apps.

Over the past few years, I have been for real disappointed that Safari did not support: Vibration API, Push API, ResizeObserver, AudioWorklets, and on and on.

And then the product people say, quite reasonably, "Well, I guess we'll just need to build a native iOS app and pay the 'Apple tax'". Over which I don't think Apple are shedding many tears...

Thank god iOS doesn’t have vibration support, we simply don’t want it

Any mention of specific APIs misses the point.

It's fine if they want don't want to implement everything.

The point is that if they don't get to simultaneously say:

1. The Web is a viable way to compete with native apps (which they explicitly said in defense in a current court case). 2. While not implementing features necessary to compete. 3. While not allowing anyone else to build a browser for iOS that implements the features necessary to compete.

I think we could have those API only enabled for Web Apps and not within Safari. But then Apple want to push everything to native App. Which is fine if it wasn't for the curation of App Store which has some benefits and problems.

You realize a user has to give permission per webpage right? Nothing wrong with Vibration Support in the browser.

Part of the standardization process involves validating stable, compatible implementations in existing browsers. If a feature is on the standards track it can’t be accepted as a recommendation without that.

Reply on news.ycombinator.com