This meant that third-party browser apps would have the same level playing field as Safari. To understand the context, here’s a quick recap.
I finally got my answer, and it is not good news. Google released a major update for Chrome yesterday, but as Martin Schurer pointed out on Twitter, the new version of Chrome doesn’t use WKWebView. Google Engineers have filled a “meta-bug” in the Chrominum open source project to track the usage of the new WKWebView instead of UIWebView. Before going into the details about why they haven’t used WKWebView, they highlight the advantages of using WKWebView:
– Faster JS (modern engine rather than the older engine UIWebView is still restricted to use)
– Crash isolation (renderer crashes wouldn’t bring down the whole app, better matching Chrome on other platforms)
– Support for IndexedDB (support for which was *not* added to UIWebView even in iOS 8)
However, they point out that despite the advantages, they can’t replace UIWebView with WKWebView as there are “significant technical limitations”:
– There is no cookie management API, which means there is no obvious way to clear/manage cookies
– Protocol handlers no longer work, which breaks several very important features
– POST bodies are missing from delegate callbacks, which breaks certain aspects of form handling
Google is currently looking at alternatives and also working with Apple on the issue. I hope that they can address the problem, so they can use WKWebView.