The disappointing reality of WKWebView

I’ve been playing around with embedding WebViews in native apps for some time now, but I’ve never managed to get to them to a point where I’d be happy to use them in an app people would actually use. The bad reputation is justified – aside from anything else, they’re just slow.

But all was supposed to change with iOS8. Apple surprised everyone with the announcement that it has created WKWebView – a new UIWebView alternative that runs out-of-process, JS bridges to native code, and brings the super-fast Nitro JavaScript engine along with it. Great! Except…

It isn’t finished yet.

At first look, it works great. Point it at a URL, it loads it, the JavaScript is fast… bliss. This will be great in the embedded WebViews in Facebook, Twitter, Chrome and the like. Now try loading a file you’ve stored locally. It won’t work. OK, read the HTML manually, then use loadHTMLString to put the HTML in the webview. That will work. But it still won’t load any external files, like JS or CSS.

You can, as I did, go further down the rabbit hole and embed your CSS and JS in-page, have everything work and then discover that remote requests have weird character set issues, or that WKWebView has no applicationCache functionality. As best I can tell, the more you work with it, the more issues you’ll discover that will hold you back.

So don’t use it for app views yet.

At least, that’s my recommendation anyway. For opening web content in modal views, sure. To integrate with your app? No. There are too many unknown caveats and undocumented issues. You would think that the inability to load local files would have been a notable enough problem that it would be fixed in iOS 8.1, but no dice.

I’m still optimistic, and I hope that in time WKWebView will be the saviour we’ve all been waiting for. But it isn’t yet.