WKWebView: Differences from UIWebView browsing engine

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 older 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.

Supports WebRTC & getUserMedia

In iOS/iPadOS 14.3, Apple added support for WebRTC (and by extension, getUserMedia requests) to WKWebView.

Issues

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.

HTML5 local storage clears when app is exited

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