Android had well over double Apple's marketshare in 2012 when FB bought Instagram for $1B, and they had yet to (or just had) released their Android app. Despite having 80% marketshare, Apple's App store generated more revenue than the Play market last quarter[1].
When the vast majority of mobile revenue is generated by iPhone users, that means if it doesn't work on iOS, it doesn't work at all - 80% marketshare be damned.
When Apple holds the most important card - revenue - its not hard to see that they are in the best position for stifling standards. If you are a developer are you going to sacrifice your revenue for standards, or play by Apple's rules?
>Google managed to get stuff done via its SPDY2 work to the point that the HTTP/2 standard adopted most of their work,
And it was something that could be deployed to the vast majority of users without a single finger being lifted from anyone outside Google.
>I totally agree but Apple's not required to work with any standard bodies. Focus on getting your standard out and then call on Apple for failing to support it when the rest of the market supports it.
Unfortunately most standards don't work this way. When standard bodies were left to their own devices, we got XHTML. Most standards seem to work like SPDY - one or two companies (Google, FB) use their market position to rollout a huge change to large number of clients and then make that the standard while everyone else cries about binary headers. In the PointerEvents case, the company with market position is Apple.
I'd imagine the best thing to do is commented on the article. Create a Polyfill, and if PointerEvents are better than the rest, developers will naturally use them. Eventually given the huge amount of developers on the polyfill Apple may be inclined to make it native.
[1]http://www.techspot.com/news/58456-google-play-vs-app-store-...