Readwrite recently published an article titled "HTML5 Has A New Best Friend—And It's Apple, Not Google", which caught my attention since they referenced some of our performance data on iOS 8. While iOS 8 is a huge update for HTML5 developers, I still think contrary to the article they are some way behind Chrome and Android. To avoid our citation being interpreted as sharing the point of view, here's the way I see it.
Safari vs. Chrome
For a long time Safari was clearly the top mobile browser, and nothing else came close. (Anyone who has ever tried to develop for the Android stock browser will probably have plenty of stories of agony to share.) However Android's transition to Chrome has done a lot to fix that.
Have a look at this caniuse.com comparison table of Safari and Chrome, covering Safari for iOS 7, iOS 8, and Chrome 37 for Android. Everything new in iOS 8 was already supported by Chrome. Safari covers a few features that Chrome lacks (such as 'sticky' positioning and MathML), but the list of features only Chrome has is much longer (touch-action, shadow DOM, dialog element, HTML imports, web animations, download attribute, getUserMedia, web crypto, WebRTC, fullscreen, and more). I'd argue many of those are major features too, especially getUserMedia and WebRTC. Safari's lack of fullscreen support is also particularly frustrating for HTML5 game developers, and has taken a step backwards in iOS 8 with the removal of minimal-ui support. Landscape mode is back to having invisible touch regions that bring back the browser UI, and portrait mode uses a smaller viewport. While Apple flip flop with their proprietary solution, Chrome has supported the standardised fullscreen API for some time now.
Android is the only mobile OS that has a stock browser on a rapid release cycle. Chrome for Android updates come on a 6-weekly update cycle. That is also why Chrome is often the first to support new features like WebGL. Every other mobile OS has a stock browser that can only update with OS updates, which tend to come infrequently and with major updates only every year or so.
Firefox for Android deserves a shout-out for equalling Chrome for Android on many of these points. However it's not managed to gain much market share, probably simply because Chrome is a strong competitor that is installed as the default. However it's interesting to note that on Android there is actual genuine choice in which browser you want to use. There is Chrome for iOS, but it's a wrapper around the Safari engine, so is largely stuck with the features Safari supports. Firefox for Android on the other hand uses its own unique Gecko rendering engine. Competition in the browser market is healthy, as the IE6 monoculture of the mid-2000s demonstrates.
The webview
The new WKWebView in iOS 8 is a major step forward for hybrid apps, and especially games. The major new features include JIT compilation for Javascript and WebGL support. The Android web view on the other hand has always supported JIT compilation. Apple were unique in crippling their web view with slower Javascript performance, a decision which frustrated hybrid app developers for years.
Android 4.4 (KitKat) moved to a Chromium-based webview, almost a year ahead of iOS 8's release. In theory this brings the same features as WKWebView, but misses some features in KitKat, particularly WebGL support and Web Audio, two essentials for HTML5 games. Android L remedies this and should bring roughly Chrome for Android parity to the web view. Of course, Android OS updates move slowly compared to iOS, but Google are definitely on the case.
Currently on both Android and iOS, the web view can only be updated with the OS. Google however are well aware of the advantages of the rapid release cycle, and have stated their intent to auto-update the web view. With both more features and regular updates, Android would have significant advantages over iOS for hybrid apps. That's yet to actually happen, but appears likely.
Conclusion
Apple's main advantage seems to be that when it releases a new version of iOS, it gets installed widely pretty quickly. The limited hardware set also allows WebGL to be supported on all devices, whereas Chrome's WebGL support is subject to blacklists.
Android OS updates take far longer to propagate, but get there eventually. The state of WebGL support is also improving over time too, with webglstats.com listing Android mobile and tablet devices as achieving 61% WebGL support on a strong upwards trend. Other than that, Android already has much of what iOS 8 gains, Chrome is already some way ahead of Safari in API support, and the future looks more promising if the web-view is auto-updating. For gaming, HTML5 developers have to continue to put up with Safari's crazy viewport restrictions with no good fullscreen or orientation lock support in iOS 8. (Note Chrome 37 doesn't yet support orientation lock, but is about to get it in Chrome 38. Rapid releases for the win!).
Apple have indeed done a great deal for the mobile web, including pioneering the Web Audio API and a GPU-accelerated canvas, and providing for a long time the only decent mobile browser. Today though Chrome for Android and the Android platform's webview looks to me like the more compelling option for hybrid development. Your move, Apple!