WKWebView – slice of Safari in your app

WKWebView was introduced in WWDC 2014 as an open source alternative to UIWebView for iOS and Mac apps.

WKWebView boasts of many advantages over UIWebView, some of which are included below:

  • WKWebView has very few/no memory leaks as opposed to UIWebView
  • WKWebView boasts Nitro javascript engine, same as used by Safari
  • Each WKWebView tab is opened in a new Process different than the app providing new and different resource pool that is separate from the app.
  • Some studies have shown that for some resource-intensive websites, the CPU usage is much lower
  • WKWebView provides key value observing (KVO) capability for web-related attributes ( change in title of webpage, estimated progress of loading of web page etc). For a detailed list of the WKWebView’s support KVO properties, refer here

Your next question should be, “What is the catch?”.

WKWebView was released without all the features of UIWebView.  Many of these are slowly being addressed over the last year. As of iOS 8.4 ( current greatest released iOS version), some of the cons are:

  • Requests made from WKWebView cannot be customized using NSURLProtocol
  • WKWebView does not have a good story defined around cookie-management ( should be fixed in iOS 9 to be released in October)
  • WKWebView cannot render content from local file unless it resides in /tmp folder.
  • As every WKWebView tab is opened in a new process, it is hard to visualize the memory consumption by WKWebView from Xcode

In my coming posts, I will focus on the gotchas related to WKWebView that I figured out while coding it up.

WKWebView – slice of Safari in your app