Why Safari got Nitro and Web Clips and UIWebView didn’t
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 a€” 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.
Ita€?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.
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.)
- iPad Live 47: Five on 2
- Apple tweaks Apple.com, adds more HTML animation
- iPad 2 tear down
- TiPb Answers: Apple A5 chip — what we know and what we guess
- Ninja Tip: How to install iMovie on the original iPad 1
- iPad vs iPad 2: RAM performance in Mobile Safari
- Bringing specs to an experience fight