Google Chrome still doesn’t use iOS 8’s WKWebView that would offer improved performance due to “significant technical limitations”

Chrome iOS 40

One of the reasons I was excited about iOS 8 was because it was supposed to bring the same Javascript performance as Safari to third-party apps.

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.

In 2011, Apple had ported Nitro Javascript engine used in desktop version of Safari to mobile Safari browser in iOS 4.3, which loaded JavaScripts two times faster. 

The reason Nitro JavaScript offers improved performance over WebKit’s previous JavaScript engine is due to the use of JIT (Just-In-Time) compilation. A JIT requires the ability to mark memory pages in RAM as executable. However, due to security reasons, iOS does not allow pages in memory to be marked as executable. Apple made an exception to the policy only for mobile Safari. Apple also does not allow third-party runtimes (due to security concerns), which in turn disallows third-party rendering and Javascript engines.

This has meant that third-party apps such as Chrome, Firefox etc and Home screen webclips that use UIWebView control don’t have access to the faster Nitro JavaScript engine. So webpages load much slower in these third-party apps as compared to mobile Safari.

iOS 8’s WebKit had addressed the security concerns, as it included improvements such as increased JavaScript performance via WebKit’s super-fast JIT. This meant that Safari wouldn’t have an unfair advantage at least in terms of performance, which is one of the key factors while deciding which browser to use by default.

When I covered the news, I had warned that we may not see the performance improvements right away as apps will have to implement the new WKWebView to take advantage of the JavaScript performance improvements. It’s been just over four months since the iOS 8 has been released, and I have been wondering why there hasn’t been a noticeable performance improvement in third party browsers and apps.

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.