With the recent r224 beta release, there is a new experimental option to enable WKWebView for iOS. This can significantly improve the CPU performance of Construct 2 games thanks to the ability to use the Javascript JIT. Let's cover this in some more detail.
What is WKWebView?
Cordova apps work by using a "web view" to run a HTML5 game. This is basically a browser control in a native app that loads a locally-stored page. Previously iOS had provided UIWebView for this purpose. However it had the significant shortcoming of not being able to compile Javascript. All modern browser engines - including the Safari browser on iOS - use JIT (Just In Time) compilation to compile Javascript to machine code for maximum performance. UIWebView had this feature disabled, so Javascript would be stuck in a slower interpreter mode.
Fortunately the industry-leading hardware performance of iOS devices allows them to muscle through and perform well in most cases regardless of this. Also WebGL support was added in iOS 8 which meant it already had excellent graphics performance. Consequently many games perform just fine with the existing UIWebView. However CPU-intensive cases stand to gain a lot from using WKWebView, and it can also help make existing games more efficient too.
Benchmarking WKWebView
Since iOS 8 added WebGL support, most of our real-world type game examples already run at 60 FPS even on lower-end iOS devices. So to investigate the performance improvement with WKWebView we'll focus on two specifically CPU-intensive examples: renderperfgl, which tests how many sprites can be rendered at 30 FPS (usually bottlenecked on how fast the CPU can issue the draw commands), and particles, a particle effect demo with around 850 particles which all need to be simulated on the CPU. To highlight the improvement we'll focus on the two oldest devices that can run iOS 9, an iPad 2 and iPhone 4S (released 2011), and also the newer iPad Air 2 (released 2014) to represent a more modern device.
First up, renderperfgl - how many sprites can be rendered at 30 FPS?
Every device shows a significant improvement: the modern iPad Air 2 is nearly 50% better, but the iPhone 4S can manage a whole 4x (400%) as many sprites! Older devices appear to benefit far more from this. I would speculate that on the iPad Air 2 it's fast enough to bottleneck on GPU performance once it can compile the Javascript, whereas the older devices are only bottlenecked on how fast the CPU can go.
Next up, how do the devices fare on the particle effect? Note this time we are measuring frames per second (FPS), capped at 60, the display refresh rate.
The iPad Air 2 was already fast enough to reach 60 FPS. The iPad 2 shows some improvement, but the iPhone 4S can hit 60 FPS with WKWebView, up from 37 FPS. It's also interesting to compare the estimated CPU usage in these cases as well. This is a ballpark figure since it's based off timing measurements in Javascript, but it still indicates a significant improvement. This time we're measuring CPU usage as a percentage 0-100.
All devices were having their CPUs strained by the UIWebView in this example, having to run at full tilt. What's impressive about this is that while the FPS measurements go up for the iPad 2 and iPhone 4S, the CPU usage also still comes significantly down. Even the iPad Air 2 which could already hit 60 FPS has gone from a fully consumed CPU to just 23% usage with plenty of idle time. This is comparable to the 4x improvement seen on the iPhone 4S in the renderperfgl test, but on a modern device. I haven't made any measurements specifically for battery life or device temperature, but freeing up so much CPU time is likely to prolong battery life and prevent the device getting so hot.
Implementation difficulties
While working on this, the new WKWebView control had some missing features which made this very tough to support. We'll cover the details of this in a separate technically-focused blog some time soon, but the short version is that WKWebView games may take longer to load and use more memory. Also we got really snookered by missing features when it came to supporting video, so unfortunately there is no support for video playback when using WKWebView. In r224 this is an option in the Cordova options dialog, so you can experiment with it and use it if it works for you.
We would encourage everyone who publishes to iOS to experiment with this option and let us know how it works out! See the r224 release notes for more information on trying it. If there are any serious problems hopefully we can correct them. We're also keen to know if the loading and memory usage proves to be a problem in practice, or if it's not too much of a worry. The performance gains are so significant that it would still be worth some impact here.
Conclusion
Using WKWebView improves CPU performance by 3-4x on both older and newer devices. This does not affect GPU performance, so games bottlenecked on rendering will probably not see much improvement. However this can still reduce the existing CPU usage, and may save battery too. The only major missing feature (that is known right now) is video support, but we encourage you to try it out and let us know how it works, so we can make sure it works as smoothly as possible so as many people as possible can take advantage of these gains!
WKWebView is likely to be where new features are added as well: it already has IndexedDB storage support where UIWebView does not. So focusing on WKWebView going forward is probably a good idea to make sure we can use any new features added later on. Hopefully future iOS releases will fix some of the implementation difficulties as well, which could re-enable features like video playback. We've filed bug 154916 with Apple to ask them to look in to this. It's definitely too early to make the WKWebView the new default, but we're optimistic we'll be able to do that eventually, and then all games published to iOS will get maximum performance!