undefined | Better HN

0 pointsmightykan10y ago0 comments

There is very much a technical reason that third-party rendering engines won’t work: JavaScript JIT. Basically, for JIT to work, a process has to be able to mark a piece of memory executable, which would cause all sorts of issues with sandboxing/security.

Apple did introduce XPC in iOS 8 and all the extensions use XPC extensively to respect the sandboxing rules. This is what they used to introduce the WebKitViewController whose JavaScript performance is on part Mobile Safari (UIWebView’s JavaScript performance is poor due to not having JIT). In fact, the new SafariViewController that was introduced in iOS 9, which is effectively an embedded Mobile Safari in third-party apps, is mainly possible because the OS has first-class support for XPC within the confines of the application sandbox.

I could see, although I’m not sure how likely it would be, Apple introducing a new Extension Point for rendering engines. Although it’s attractive to attribute malice to their intentions, I don’t think Apple are actively enforcing the “all third-party browsers have to use WebKit" for any other reason than security and battery life impact. If they could find a way to allow third-party rendering engines/browsers to work within the confines of the application sandbox, be secure and have insignificant impact on the battery life, they would allow it. They’re almost there technically, anyway.

0 comments

1 comments · 1 top-level

mikeash10y ago

Since UIWebView doesn't do JIT, as you say, and third party browsers using UIWebView are allowed, I don't think this theory holds up. The inability for third-party engines to do JIT certainly is a problem, but it doesn't look like the problem that causes Apple to make this restriction.

j / k navigate · click thread line to collapse