Google Shifts Chrome for iOS to Apple’s WKWebView, Reducing Crashes by 70%

MacRumors

macrumors bot
Original poster
Apr 12, 2001
49,654
10,976



Google today introduced a few stability and performance improvements into its Chrome for iOS app, mainly centering around the company's switch from in-process rendering with UIWebView to out-of-process rendering thanks to WKWebView. Tests by Google proved the new update reduces the app's crash rate by 70 percent, letting users pick up where they left off on a page from any device without a crash causing issues.

The biggest change is in stability: with WKWebView's out-of-process rendering, when the web view crashes or runs out of memory, it won't bring down all of Chrome with it. As a result, Chrome crashes 70% less with WKWebView. Even when counting the "Aw, Snap!" page shown when the renderer crashes, there's still a big improvement.

Outside of stability, WKWebView brings many other benefits. Web compatibility is improved with support for features like IndexedDB, bringing the HTML5test score for Chrome on iOS from 391 up to 409. Switching to background tabs will cause pages to reload 25% less often. JavaScript speed on benchmarks such as Octane is an order of magnitude faster, and scrolling is smoother and more responsive.
For the web, Google also created a new extension called "Data Saver," that will allow Chrome users the ability to manage data usage while outside of their home Wi-Fi. Similar in function to the extension available for Android devices, Data Saver reduces the data needed to access the web with the help of the company's "compression technology." The extension lets users see exactly how much data they saved and highlight which websites are using the most while out of the house.

Google said that the iOS Chrome update will begin rolling out starting today, and all users have to do is check for the update in the App Store [Direct Link] if they don't feel like waiting for an automatic update.

Article Link: Google Shifts Chrome for iOS to Apple's WKWebView, Reducing Crashes by 70%
 

clauzzz203

macrumors 6502
Sep 18, 2012
428
423
So they are still using a skin over iOS Safari but instead of the second-most-obsolete release of Safari, it’s now just the obsolete version of Safari

Edit, actually the desktop version’s WebKit core comes from an Apple open source project, so it’s fitting
 

Studioman

macrumors regular
Jun 17, 2015
135
194
I'm wondering why the only major article on wkwebview which is a year and a half old and has been in safari since iOS 8 is when Google finally decides to use it. Odd on an Apple fan page.
 

ck2875

macrumors 6502a
Mar 25, 2009
996
2,594
Brighton
When I updated it said that due to this switch that the Data Saver, "Do Not Track", and Cookie options were no longer available due to limitations on Apple's WKWebView.

While that makes sense for Data Saver, I feel like that is just Google being Google and wanting to track the F out of you with removing the "Do Not Track" & cookie options. Perhaps I'm wrong though.

Edit: Here's the Google Support Page that says it...

Google said:
Some of your Chrome features and settings will not be available at this time because of iOS constraints. Downloads that require authentication might not work, and the following features and settings had to be removed:

If Apple makes changes to WKWebView to allow these features, we will add them back in.
 
Last edited:

viachicago22

macrumors 6502
Sep 20, 2013
334
90
So they are still using a skin over iOS Safari but instead of the second-most-obsolete release of Safari, it’s now just the obsolete version of Safari

Edit, actually the desktop version’s WebKit core comes from an Apple open source project, so it’s fitting
So forgive my technological ignorance, but I understand that all third party browsers for iOS have always been slower than Safari due to restrictions from Apple that I don't fully understand. Does this change mean that Chrome could now rival Safari for speed?
 

Traverse

macrumors 604
Mar 11, 2013
6,917
3,225
Here
The biggest feature that keep see bound to Safari is Reading List. I don't know how many people here use it, but I've used it every day since Safari 5.1! Right now I have about 100 articles. Yes, there are third party services that can do this or you can even save them in a Bookmark folder for later, but with Safari it's built in!

As long as Reading List remains a Safari-only feature*, I'll use Safari for personal browsing and Chrome for business-related stuff.

*I believe Microsoft Edge has a similar feature now
 

dor.pnhs

macrumors newbie
Sep 21, 2012
11
5
I'm wondering why the only major article on which is a year and a half old and has been in safari since iOS 8 is when Google finally decides to use it. Odd on an Apple fan page.
Because it is major regardless the Google-Apple competition.
The real question is why it took a long time to google to release it.
 

KALLT

macrumors 603
Sep 23, 2008
5,148
3,192
So forgive my technological ignorance, but I understand that all third party browsers for iOS have always been slower than Safari due to restrictions from Apple that I don't fully understand. Does this change mean that Chrome could now rival Safari for speed?
Basically, developers have to use Apple’s APIs to write their apps. For web content, Apple provides the UIWebView class and the WKWebView class since iOS 8. The problem with these is that they were never meant for creating fully-fledged browsers, but for showing web content within apps. Safari likely uses a lot more functionality than Apple exposes through these two classes, so third-party browsers can simply never compete effectively.

Does this mean that ios9 content blockers will now work with Chrome?
Nope. Only Safari and the new SFSafariViewController class. The latter cannot be meaningfully used for a browser apps.
 
  • Like
Reactions: viachicago22

atrevers

macrumors regular
May 24, 2007
128
27
UK
Edit, actually the desktop version’s WebKit core comes from an Apple open source project, so it’s fitting
Not quite that simple - Chrome for the desktop now uses Blink, a forked version of WebCore, which is the rendering library component of WebKit. Google themselves have been the largest contributor to WebKit since 2009.
 

Glassed Silver

macrumors 68020
Mar 10, 2007
2,096
2,559
Kassel, Germany
On iOS the only thing that keeps me invested in Safari is the integration with my Mac and that it's a system default.

On OS X Safari wins usually, but I encountered several annoyances with it recently and before, which tempts me to make the switch eventually.
As I'm on a desktop computer there's no worrying about battery life as well. (something that Google will likely fix eventually anyways, as a lot of Google employees actually use Macs themselves and likely get sick and tired of this too... At least I'd hope so. Guess it's not an easy fix as it might involve some fundamental changes to the engine.)

Glassed Silver:mac
 

ericg301

macrumors 65816
Jun 15, 2010
1,431
939
Does this mean that ios9 content blockers will now work with Chrome?
THIS.

biggest reason i switched back to safari when ios 9 came out. didnt realize how much better the mobile web could be with content blockers.
 

C DM

macrumors Sandy Bridge
Oct 17, 2011
49,765
18,272
Because it is major regardless the Google-Apple competition.
The real question is why it took a long time to google to release it.
I recall reading somewhere at one point that the transition wasn't a trivial one at all and basically required more or less quite a bit of a rewrite. There were some things that weren't available or easily done with the new view that seemingly needed time to be worked out.
 

ericg301

macrumors 65816
Jun 15, 2010
1,431
939
i dont know why Google Now isn't part of Chrome. Or at least an option to set it as your home page
 

WordMasterRice

macrumors 6502a
Aug 3, 2010
734
100
Upstate NY
I recall reading somewhere at one point that the transition wasn't a trivial one at all and basically required more or less quite a bit of a rewrite. There were some things that weren't available or easily done with the new view that seemingly needed time to be worked out.
This is more or less correct. WKWebView has a lot of limitations compared to UIWebView from an API standpoint, especially when it came out. I tried to adapt one of my apps to it and it just wasn't possible at the time.
 
  • Like
Reactions: kdarling

amro

macrumors 6502
Jul 7, 2008
369
34
Digg seems a hell of a lot better. Scrolling was jumpy at best and Chrome would crash almost every time I used it.
 

JTravers

macrumors 6502a
Jun 28, 2010
682
195
Because it is major regardless the Google-Apple competition.
The real question is why it took a long time to google to release it.
Some reasons....
https://code.google.com/p/chromium/issues/detail?id=423444
This is a meta-bug to track using the new WKWebView instead of UIWebView on iOS 8+. This would have several advantages we're aware of:
- 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)


Unfortunately, despite the advantages of WKWebView, it has some significant technical limitations that UIWebView does not, which means we can’t simply drop it in as a replacement. A partial list of regressions relative to UIWebView that we’re currently aware of:
- 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

We’re still actively investigating WKWebView, looking for possible alternate approaches, and providing feedback to Apple about issues. We certainly hope to use WKWebView in the future, but there’s currently no way of knowing if or when that will be possible.
 
  • Like
Reactions: Glassed Silver
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.