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

Now, just fix Chrome for OSX and we might have a story

Now, just fix Chrome for OSX and we might have a story

The way it drinks battery is incredible with one tab open - I can have 10 tabs in safari and it would use less energy than 1 tab in chrome

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

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.

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.

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.