iOS 8, WebKit Performance, and XPC

Mike Beasley, writing for 9to5Mac:

When iOS 7 launched, developers discovered that their apps with built-in web browsers were unable to achieve the same level of JavaScript performance as the stock Safari app. This was because Apple restricted use of its improved Nitro JavaScript engine to its own app, leaving third-parties with a slower version.

As of iOS 8, however, it seems that decision has been reversed. All apps will now be able to use the same improved JavaScript engine that powers Safari. That means Google’s Chrome browser on iOS will now be just as quick as Safari, as will the pop-up browsers embedded in apps like Twitter and Facebook.

The Nitro JavaScript compiler appeared all the way back in iOS 4.3 in 2011, and there has been a split in performance between Mobile Safari and third-party apps ever since. As I wrote then:

The real answer is about security. Perhaps the biggest reason for Nitro’s performance improvements over WebKit’s previous JavaScript engine is the use of a JIT — “Just-In-Time” compilation. Here’s Wikipedia’s page on JIT. A JIT requires the ability to mark memory pages in RAM as executable, but, iOS, as a security measure, does not allow pages in memory to be marked as executable. This is a significant and serious security policy. Most modern operating systems do allow pages in memory to be marked as executable — including Mac OS X, Windows, and (I believe) Android. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.

What’s new in iOS 8 is not that a “decision has been reversed”. It’s that inter-application communication APIs — XPC — have been greatly improved. This is why we’ve got all sorts of new stuff: third-party keyboards, sharing extensions, photo filters, and a full-speed embedded WebKit. All very different, all enabled by XPC.

In the old days, things like this were insecure and dangerous: plug-ins executed inside applications. A bug in a plug-in could crash your app or create security vulnerabilities. iOS never allowed that. Now, with improved XPC, we have extensions that run as separate sandboxed processes. This isn’t something Apple tackled in the past year alone — they’ve been working on iOS XPC for years, but only now in iOS 8 is it ready to be opened to third-party apps.

★ Monday, 9 June 2014