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
its own app, leaving third-parties with a slower version.
As of iOS 8, however, it seems that decision has been reversed.
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 real answer is about security. Perhaps the biggest reason for
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