As we posted the other day, while Safari in iOS 4.3 got a huge speed boost thanks to the Nitro JavaScript engine, asynchronous mode, and HTML 5 caching, bookmarking a site to the Home Screen (Web Clips) that launch in full-screen mode, or browsing inside an app (UIWebView) didn't. That meant, while web apps on the home screen and web pages embedded in apps were as fast as they were in iOS 4.2, they weren't as fast as Safari in iOS 4.3.
The technical reason for this is because Nitro is using Just-in-Time (JIT) compilation. Daring Fireball says:
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) Android1. iOS 4.3 makes an exception to this policy, but the exception is specifically limited to Mobile Safari.
It’s a trade-off. Most OSes allow marking memory pages as executable for performance reasons. iOS disallows it for security reasons. If you allow for pages of memory to be escalated from writable to executable (even if you require the page be made permanently read-only first), then you are enabling the execution of unsigned native code. It breaks the chain of trust. Allowing remote code to execute locally turns every locally exploitable security flaw into a remotely exploitable one.
So if you load a page in Safari or have a Home Screen bookmark that launches into Safari, you get Nitro because Apple trusts Safari (which given how big an attack target Safari has is... interesting.) If, however, you load a page in an app using UIWebView you get the old JavaScript engine because Apple doesn't trust that app. If you launch a Home Screen bookmark that includes specific code for full screen mode, Safari doesn't pick it up but it opens in Web.app and -- for some reason -- Apple doesn't trust that either (yet?).
WebKit2 -- which iOS 4.3 doesn't seem to be using -- could address this because it uses split processes built into the frameworks but there's no word on when or if Apple will implement it in iOS. (It's reportedly implemented in Mac OS X Lion beta.)
So no conspiracies, just the usual trade offs between security and convenience and the limits of Apple's resources to get everything done all at once. (We won't put the pitchforks and torches away altogether, however, and Web.app gets Nitro, and everything gets WebKit2.)
