New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 164 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2016
EstimatedDays: ----
NextAction: ----
Pri: 2
Type: Bug

Blocked on:
issue 390660
issue 450311
issue 450362

issue 136610
issue 420630
issue 468179
issue 468258
issue 525262

Sign in to add a comment

Issue 423444: Use WKWebView on iOS 9+

Reported by, Oct 14 2014 Project Member

Issue description

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.

Comment 1 by, Oct 14 2014

 Issue 412906  has been merged into this issue.

Comment 2 by, Oct 14 2014

Issue 382663 has been merged into this issue.

Comment 3 by, Oct 14 2014

Relevant Radars filed for the more significant limitations:
- Lack of cookie management (rdar://17486250, rdar://18180302)
- Lack of protocol handling (rdar://17177376)
- Missing request bodies (rdar://18399639)
- File upload issues (rdar://18350812)
- Limited SSL cert handling (rdar://18494626, rdar://18517043)

Comment 4 Deleted

Comment 5 by, Oct 23 2014


Comment 6 by, Nov 17 2014

I think this is the perfect time to create a separate beta version specifically for testing new features such as this. WKWebView support is already late, don't make us wait into next year please.

Comment 7 by, Nov 17 2014

It's not a question of testing, it's a question of fundamental limitations in WKWebView as explained above. It doesn't make sense to describe it as "late", since the summary above is very clear that we don't have a timeline for switching due to those limitations.

It would have been great if WKWebView had been an unambiguous improvement over UIWebView so that switching was just a case of doing the technical work to adopt the new APIs, but that's unfortunately not the reality of what Apple provided in iOS 8.

Comment 8 by, Nov 17 2014

If possible (I'm not familiar with how secret are those submissions) please post updates to reported rdars in this bug (especially if they're fixed/wontfixed).

Comment 9 Deleted

Comment 10 by, Jan 7 2015

Blockedon: chromium:390660

Comment 11 by, Jan 7 2015

Blocking: chromium:420630

Comment 12 by, Jan 20 2015

Blockedon: chromium:450311

Comment 13 by, Jan 20 2015

Blockedon: chromium:450362

Comment 14 by, Jan 23 2015

Was wondering if there have been any updates to address the limitations of WKWebView. Is it safe to assume that Chrome for iOS will not be using WKWebView for the foreseeable future?

Comment 15 by, Jan 26 2015

iOS 8.1 did not address any of the API limitations described above.

Comment 16 by, Jan 27 2015

Chrome on iPad runs like crap because of UIWebview.  The version for the iPhone is not so bad maybe because a lot sites have mobile versions which are optimize for mobile browsers.  However, chrome for iPad typically run full websites which tend lag and have scrolling issues.  Putting WKWebView should be a priority for the iPad despite the limitations because the current chrome has serious performance issues.

Comment 17 by, Feb 25 2015

Labels: Hotlist-WKWebView

Comment 18 by, Mar 18 2015

Blocking: chromium:468258

Comment 19 Deleted

Comment 20 Deleted

Comment 21 by, Apr 6 2015

If WKWebView solves problems like Safari's arbitrary 50MB size limit on websql data, then using it would be an opportunity for Chrome to become a superior browser to Safari. My company produces an app that saves lots of data in websql and we would love to be able to recommend Chrome over Safari if it could get us out from under the 50MB data size limitation in Safari.

Comment 22 by, Apr 6 2015

WKWebView currently has no API related to configuring storage limits or requesting increases in storage.

Comment 23 by, May 3 2015

Labels: hotlist-ios-fixit

Comment 24 by, May 6 2015

Labels: hotlist-ios-fixit-stuartmorgan

Comment 25 by, May 6 2015

Labels: -hotlist-ios-fixit-stuartmorgan

Comment 26 by, May 7 2015

Labels: hotlist-ios-fixit-msarda

Comment 27 by, May 7 2015

Labels: hotlist-ios-fixit-done
Status: Assigned

Comment 28 by, May 25 2015

Did iOS 8.3 make any difference in the list of issues?

Comment 29 Deleted

Comment 30 by, May 26 2015

> Did iOS 8.3 make any difference in the list of issues?


Comment 31 Deleted

Comment 32 Deleted

Comment 33 Deleted

Comment 34 Deleted

Comment 35 by, Jun 15 2015

Apple has recently released WKWebsiteDataStore, does it resolve anything?

Comment 36 by, Jun 15 2015

WKWebsiteDataStore appears to make it possible to delete cookies, so it addresses part of one bullet of comment 3 (which is itself not an exhaustive list of issues)

Comment 37 by Deleted ...@, Jun 18 2015

The implementation of WKWebsiteDataStore is not completed yet. We can expect more changes to it in the up coming betas

Comment 38 by, Jul 8 2015

Not sure if this on the radar for this bug, but it seems to be a rather crippling experience.  Please see  for details.

Basically interaction with an input field inside an iframe is crippled.

Comment 39 by, Jul 8 2015

We are keenly aware of all the differences that have come up in bugs between UIWebView and WKWebView.

The problem here is not a lack of awareness on our part, it's that some aspects of WKWebView on iOS 8 are also crippling.

Comment 40 Deleted

Comment 41 by, Aug 31 2015

Blocking: chromium:525262

Comment 42 by, Sep 1 2015


Comment 43 by, Sep 6 2015

Blocking: chromium:136610

Comment 44 by, Sep 7 2015

Would it be possible to do some kind of hybrid between UIWebView and WKWebView? Somehow make requests via UIWebView and process them via WKWebView?

Comment 45 by, Sep 29 2015

We are running into a number of issues on Chrome iOS that are not present in iOS Safari including:
- xhr upload progress callback is not fired.
- file picking fails randomly on iOS 9.
- "cloud" images (from new iOS 9 photo picker) fail to upload.
- clipboard API doesn't work.
- transition animation issues.
- general responsiveness.

I wonder when it will get to the point that the pros of being on WKWebView outweigh the cons. For now, we are just going to message our users that they will have a better experience with Safari. But as I have been using chrome iOS personally, I find that kind of sad.

Comment 46 by, Sep 29 2015

Could you file new specific bugs about each of those things (except the general responsiveness, since I think we have a good handle on the UIWebView/WKWebView differences there) with repro cases/steps?

We're actively tracking UIWebView/WKWebView differences, precisely because of the tipping point you're referring to. We have an experimental version of the web layer based on WKWebView under active development, and I like to have our team test to see whether those are all due to UIWebView vs WKWebView (as opposed to something Safari-specific)

Comment 47 by, Nov 12 2015

Blocking: chromium:468179

Comment 48 by, Dec 3 2015

We're currently running a small experiment with WKWebView in version 47, which will give us more quantitative data about how WKWebView compares to UIWebView in actual use.

Comment 49 by, Dec 3 2015

Great news :)

Comment 50 by, Dec 14 2015

Firefox on iOS is crashing on window.openDatabase() due to WKWebView
"SecurityError: DOM Exception 18: An attempt was made to break through the security policy of the user agent."

Comment 51 by, Dec 14 2015

Re #50 -- FWIW, we're in contact with the Chromium folks, including Stuart, and we're sharing solutions wherever we can.

Comment 52 by, Jan 3 2016

Hey - is there an ETA or expected version number using WKWebView? This has been going on for over a year and it'd be interesting for developers to know if it's a good idea to spend time fixing UIWebView specific bugs that don't happen in WKWebView.

Comment 53 by, Jan 19 2016

Labels: -hotlist-ios-fixit -hotlist-ios-fixit-msarda -hotlist-ios-fixit-done
Summary: Use WKWebView on iOS 9+ (was: Use WKWebView on iOS 8+)
Updating the title; several blocking regressions (e.g., inability to continue past SSL warnings) were only addressed in iOS 9, so we don't consider WKWebView on iOS 8 viable for Chrome.

Comment 54 by, Jan 27 2016


Comment 55 by, Jan 27 2016

Labels: M-48
Status: Fixed
As announced here:
version 48 switches to WKWebView.

Worth noting is that for some users the switch to WKWebView may not happen on the first launch of M48 (due to on-disk state related to the previous shutdown). This is particularly true if the browser is currently in incognito mode.
- You can check which web view you are using with (which checks for the presence of IndexedDB support)
- If you are running version 48 but see that you are using UIWebView, you can accelerate the change-over by ensuring that you are not in incognito mode, then terminating the Chrome process by double-tapping the home button and swiping up on the Chrome snapshot.

Comment 56 by, Mar 9 2016

Labels: -Hotlist-WKWebView Hotlist-WkWebView
Hey Stuart, I'm wondering how you guys got past the issues presented by WKWebView being sandboxed and the protocol handlers no longer working.

Comment 57 by, Mar 9 2016

Why the label change? The official name is WKWebView, not WkWebView.

Comment 58 by, Mar 9 2016

(The label case change seems to be a side-effect of the bug system migration.)

There's no single answer to the issue of protocol handlers no longer working. In some cases (e.g., WebUI) we were able to implement completely different approaches. In others (e.g., cert handling, cookie clearing) iOS 9 added APIs that enabled at least some of what we needed. And unfortunately a number of features had to be removed (<>) because they could not be implemented without access to the network requests issued by WKWebViews.

Comment 59 by, Mar 9 2016

Thanks for the reply Stuart! I was hoping you'd found some clever work-around but the answer I was interested in sadly is that you removed the features that depended on access to the network requests.

Sign in to add a comment