New Chrome for iOS is finally as fast and stable as Safari

Google Chrome 48, which is being released to the browser’s stable channel today, is just another incremental update for most of the browser’s users. For Chrome users on iOS, however, it’s a big one—possibly the biggest single update since the iOS version was first released back in 2012—and it’s all because of an under-the-hood switch.

The short version is that Chrome 48 on iOS will be as fast as Safari on iOS for the first time ever thanks to a switch from iOS’ UIWebView rendering engine to the WKWebView engine introduced in iOS 8 back in late 2014. If you don’t spend your time reading Apple’s developer documentation, we’ll walk you through the state of third-party Web browsers on iOS and just why this change is such a big deal for Chrome users.

Third-party browsers on iOS

On Android and the major desktop platforms, different browsers use different rendering engines. Safari uses WebKit, Microsoft Edge uses EdgeHTML, Chrome uses Blink, and Firefox uses Gecko. On iOS, Apple has never allowed third-party browsing engines. Developers can build browsers, but they’re always just wrappers for the platform’s Webkit-based first-party engine. The oldest API for this in iOS is called UIWebView.

Way back in iOS 4.3, Apple started using a new version of the Webkit JavaScript engine called Nitro. Formerly known as SquirrelFish Extreme, this engine dramatically improved Safari’s JavaScript performance, but the catch was that Apple didn’t make Nitro available to third parties via UIWebView. The company cited security concerns at the time.

The upshot was that third-party browser makers could neither use their own browsing engines nor use the best possible version of Apple’s engine. They could offer their users familiar UIs and cross-platform syncing, but from iOS 4.3 to iOS 7.1, third-party browser makers (and any app developers that used UIWebView to render pages within their apps instead of bouncing users out to Safari) had to settle with second-rate JavaScript performance on iOS among other problems.

Fast-forward to iOS 8, and Apple finally made Nitro available to developers via a new API called WKWebView. WKWebView was a huge improvement over UIWebView in a lot of ways, but there were some missing features for browser developers. The Chrome team’s biggest problems with the API are laid out in this page on the Chromium issue tracker, but it’s clear that the original version of the API was made with apps like Facebook in mind, apps where people visit pages but don’t serve as anyone’s primary browser. Luckily, many of these problems were fixed in iOS 9.

“There were things related to cookie management, there were things related to security and our view of the Apple security stack, which would have made us lose certain functionality related to knowing more about the SSL certificate,” AbdelKarim Mardini, a Chrome Product Manager at Google, told Ars.

Mardini said that Google worked with Apple extensively between the release of iOS 8 in September of 2014 and the release of the first iOS 9 beta in June of 2015. “Apple did fix or provide some APIs in iOS 9 that made us consider the migration."

Not just about speed (but the speed is nice, too)

The most visible benefit of WKWebView in Chrome is going to be its speed. JavaScript performance gets a huge boost, best shown off in a heavier benchmark like Google Octane. Not everything is going to get ten times faster, but the speed improvement should be readily visible.

Chrome’s stability on iOS should also see a big improvement. The UIWebView process in older versions needed to run within the Chrome process, so if a complex or badly behaving page made UIWebView crash, it would bring the whole Chrome browser down. With WKWebView, Google can move the process for individual pages outside of the app, better approximating the process isolation that Chrome uses on other platforms. Now when a page crashes, you’ll see the standard “Aw, Snap” Chrome error page. Google estimates that Chrome 48 will crash 70 percent less than older versions.

Google promises improvements in scrolling and responsiveness as well, and WKWebView brings with it better HTML5 compliance and faster WebGL performance for browser-based 3D applications. An iOS 8-era comparison of UIWebView and WKWebView demonstrates these improvements. One WebGL test ran twice as fast in WKWebView, and another used 25 percent of the CPU to render particles at 60fps where UIWebView uses 90 percent of the CPU to accomplish the same task.

There is at least one missing feature, though. Mardini tells us that Chrome’s Data Saver feature, which compresses pages server-side before delivering them to users, will no longer work in Chrome for iOS. This may be disappointing for some users with low data caps or slow connections, but it’s worth noting that Data Saver doesn’t work with encrypted pages, which are increasingly common.

Finally, there are still some areas where Safari is going to have the advantage on iOS by virtue of being the platform’s first-party browser. Users still can’t change their default browser to Chrome, for instance, and the new Safari View Controller feature introduced in iOS 9 lets third-party apps use passwords and other autofill data from Safari but not from other browsers. Third-party apps still need to play by slightly different rules than Apple’s own apps in iOS, and that's unlikely to change.

Even so, Chrome users ought to be very happy with today’s update—it's available for download in the App Store now.

Listing image by Andrew Cunningham