WKWebView: Differences from UIWebView browsing engine

Advantages

Issues

Advantages

Runs outside of the app's main process

WKWebView runs out of process, meaning that its memory is threaded separately from the app; when it exceeds its allocation, it will crash without crashing the app (which results in the app being notified and attempting to reload the page). 

In contrast, UIWebView runs in process, which means that the memory it uses is considered to be part of the app's footprint and, if this exceeds what iOS wants to allocate, the app itself will be crashed by the operating system. While there is often a notification from iOS before this occurs that can allow us to avert a crash, this is sometimes either not returned quickly enough to act on or isn't returned at all. 

Uses Nitro, a faster JavaScript engine

WKWebView uses the Nitro JavaScript engine, also used by mobile Safari, which comes with significant performance improvements over UIWebView's JavaScript engine.

Handles JavaScript asynchronously

Communication between JavaScript and native code is handled asynchronously in WKWebView, which means that in general things execute more quickly. 

In practice, this means that calls from our JavaScript API will not block the thread and callback functions must be used wherever a result has to be returned before the next step is completed. For example, in one of our older ‘Save Data’ examples, we had previously used the following: 

var filenameID;
	function getFilenameID() {
	window.kp_requestKioskId("kp_requestKioskId_callback");
}
function kp_requestKioskId_callback(kioskId) {
	filenameID = kioskId.split(" ").join("");
}
function saveData(fileName, data) {
	getFilenameID();
	kp_FileAPI_writeToFile(filenameID + ".xls", data, "writeFile_callback");
}

with the assumption that when the ‘saveData’ call was triggered, the ‘getFilenameID’ function would block the thread and return a value before proceeding with the ‘kp_FileAPI_writeToFile’ call.

In WKWebView since JavaScript that communicates with native code is executed asynchronously, the ‘getFilenameID’ call is not completed before the ‘kp_FileAPI_writeToFile’ call is executed, resulting in an undefined filename. To successfully pull the device ID for use as the filename, this had to be restructured to use callbacks instead:

var filenameID;
function getFilenameID() {
	window.kp_requestKioskId("kp_requestKioskId_callback");
}
function kp_requestKioskId_callback(kioskId) {
	filenameID = kioskId.split(" ").join("");
	kp_FileAPI_writeToFile(filenameID + ".xls", data, "writeFile_callback");
}
function saveData(fileName, data) {
	getFilenameID();
}

Eliminates certain touch delays

The UIWebView and WKWebView browser components interpret and pass touch events to the app. As a result, there's no way for us to increase the sensitivity or speed of a touch event.

UIWebView adds a  300ms delay after you touch anything to determine whether the user is single or double clicking. This delay is one of the most prominent reasons that HTML-based web apps are considered "sluggish" by many users.

In WKWebView, testing has shown that the 300ms delay is only added after a fast tap (<~125 ms), which the iOS interprets as more likely to be part of a double-click 'tap-to-zoom' gesture, and not after a slow tap (>~125 ms).  More detail on this   here

To eliminate the touch delay for all tap events, including fast taps, you can add  FastClick or another library that eliminates this delay into your content.

Supports server-side authentication challenges

Unlike UIWebView, which does not support server authentication challenges, WKWebView does. In practical terms, this means that when using WKWebView, you can enter site credentials for password protected websites.

Supports authenticating self-signed security certificates & certificates with errors

WKWebView allows you to bypass errors in security certificates (for example, when using self-signed certificate or an expired certificate) through a ‘Continue’/’Cancel’ popup.

Issues

Requires iOS 9 or later

Our WKWebView integration is only available for devices that are running iOS 9 or later. While WKWebView was introduced in iOS 8, there are significant limitations in those versions, including the inability to access locally stored files, that we are unable to work around so this feature is not backwards-compatible.

Does not support AJAX requests to locally-stored files

WKWebView does not allow XHR requests to file:// URIs as these violate the browser engine's cross origin resource sharing rules. Projects that use this type of request should either be hosted remotely on a server or use the existing UIWebView browsing engine.

Does not support 'Accept Cookies' setting

While WKWebView does support the use of cookies, it does not expose the ability to select which cookies are accepted by source. This means that the ‘Accept Cookies’ setting is not applied when using the WKWebView browsing engine.

WKWebView only allows us to access the name of a cookie, not additional information like the creation/expiration date or path, making it more difficult to troubleshoot issues with cookies if they arise.

Does not support 'Advanced Cache Settings'

‘Cache Source’ and ‘Only Notify Browser of Server Redirection Events’ are not applied when using the WKWebView browsing engine.

HTML5 local storage clears when app is exited

HTML5 local storage is cleared when the app is exited and relaunched.

Does not support logging of WebKit requests

While this type of troubleshooting log is generally only used by Kiosk Pro’s support team, it’s worth mentioning that, because WKWebView makes requests and renders content out of process, Kiosk Pro doesn’t have direct access to this type of request and is unable to log them.

May not capture screenshots as expected

While we have not seen any issues with screen capture using Kiosk Pro’s JavaScript API in testing, other iOS developers have reported with screen captures failing randomly on WKWebView. If using this API for critical operations, we recommend using the existing UIWebView browsing engine.

Still stuck? How can we help? How can we help?