Hacking something useful out of WKWebView

We recently announced support for WKWebView in iOS apps with significantly improved performance, but some caveats about memory usage and video support. This was a pretty difficult bit of hacking on WKWebView to work around some serious limitations. What we found is probably useful for any Cordova app, and provides the nitty gritty details for technically-minded Construct 2 users, so here's a deep dive in to how to bend WKWebView in to something relatively useful.

As is well-known, the main reason to support WKWebView is the fact it supports JIT compilation of Javascript. This makes JS code several times faster. Obviously for a game engine, this is a must-have feature. So we went in to this with a great motivation to do anything possible to make it work.

Why not use a local web server?

If you can, do. This solves most of the problems. However it's kind of crazy to have to run a HTTP server just to get a local app to work. There may be security implications, there could be conflicts with other apps (e.g. around choosing ports), and there are probably some weird side effects like the user can probably also load your app in Safari. We also want to stick to officially supported features to have better guarantees about things like whether features will build and work, and it's important it works with build services like PhoneGap Build for Construct 2 users. None of the options I could find worked out very well:

• Cordova Local WebServer appears to be some kind of labs experiment which isn't very actively developed or used (it has no issues, for example). PhoneGap Build didn't seem to know about this plugin, so I moved on.
• CorHttpd failed to build with the latest Cordova iOS version.
• The Telerik WKWebView plugin doesn't use the official WKWebView support, which we wanted to use. Apparently it doesn't work with the latest Cordova versions anyway.

In particular, choosing a port for the preview server is surprisingly hard. You have to always use the same port, otherwise stored data disappears (since each port counts as its own origin) - but what if your chosen port is in use? How do we make sure all apps built with Construct 2 always use the same port, and yet guarantee it is never used by any other app? Imagine 10,000 apps in the store using this approach, all needing their own constant but unique port. This still doesn't sound easy to work with. So I decided to try making it work without a local web server.

Loading the index page

Luckily Apple in iOS 9 fixed a problem where you, erm, couldn't load a HTML document in WKWebView. This is the main reason Cordova has been able to add official support for WKWebView in iOS 9. So your index page appears in the WKWebView, then... nothing else works.

Just a brief aside: how do you detect if you're in WKWebView? Apparently there's no obvious way to do this, except rely on the fact WKWebView supports IndexedDB but UIWebView does not. So our detection looks like "if iOS and Cordova and window.indexedDB".

Loading local files

One of the first things Construct 2 does when loading is to load the game's main data JSON file via XMLHttpRequest. This does not work in WKWebView: it appears to treat local files as if they came from a remote server, even though they're in the app itself, and such requests are blocked.

By the way, just to make this more fun, the same thing happens to scripts. Scripts can actually load from "remote" (in this case local) locations and still run, with one difference: to prevent information leaking across domains, Javascript errors are hidden. They just turn in to "Script error" on line 0, regardless of what went wrong. So you cannot get any useful information from errors! So we did a bunch of debugging with "alert" :P

However cordova-plugin-file allows us to access local files in the app. It's hardly documented, but after digging around, you can read a local text file like this:

function fetchLocalFileViaCordova(filename, successCallback, errorCallback)
{
	var path = cordova.file.applicationDirectory + "www/" + filename;

	window.resolveLocalFileSystemURL(path, function (entry)
	{
		entry.file(successCallback, errorCallback);
	}, errorCallback);
};

function fetchLocalFileViaCordovaAsText(filename, successCallback, errorCallback)
{
	fetchLocalFileViaCordova(filename, function (file)
	{
		var reader = new FileReader();
		
		reader.onload = function (e)
		{
			successCallback(e.target.result);
		};
		
		reader.onerror = errorCallback;
		reader.readAsText(file);
		
	}, errorCallback);
};

// e.g.: fetchLocalFileViaCordovaAsText("file.txt", function (text) { ... })

function fetchLocalFileViaCordovaAsArrayBuffer(filename, successCallback, errorCallback)
{
	fetchLocalFileViaCordova(filename, function (file)
	{
		var reader = new FileReader();
		
		reader.onload = function (e)
		{
			successCallback(e.target.result);
		};
		
		reader.readAsArrayBuffer(file);
	}, errorCallback);
};

function fetchLocalFileViaCordovaAsURL(filename, successCallback, errorCallback)
{
	// Convert fake Cordova file to a real Blob object, which we can create a URL to.
	fetchLocalFileViaCordovaAsArrayBuffer(filename, function (arrayBuffer)
	{
		var blob = new Blob([arrayBuffer]);
		var url = URL.createObjectURL(blob);
		successCallback(url);
	}, errorCallback);
};