By John Gruber
Build internal tools in minutes with Retool, where visual programming meets the power of real code.
Along a similar line to today’s story about the performance differences between Mobile Safari and the system-wide UIWebView control in iOS 4.3, was Tuesday’s mini-brouhaha about web app performance outside Mobile Safari. The Register, as usual, sensationalized it best, in a story headlined “Apple Handcuffs ‘Open’ Web Apps on iPhone Home Screen”:
Apple’s iOS mobile operating system runs web applications at significantly slower speeds when they’re launched from the iPhone or iPad home screen in “full-screen mode” as opposed to in the Apple Safari browser, and at the same time, the operating system hampers the performance of these apps in other ways, according to tests from multiple developers and The Register.
“Apple is basically using subtle defects to make web apps appear to be low quality — even when they claim HTML5 is a fully supported platform,” says one mobile web app developer, who asked that his name not be used.
The obvious question: Why? The cynical answer is that Apple seeks to discourage the use of home screen web apps. But if that were the case, why don’t apps from the App Store get Nitro either? Many, many App Store apps use embedded UIWebView controls for displaying web content.
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.
Apple, as of iOS 4.3, trusts Mobile Safari enough to allow this. The upside is that Mobile Safari is now significantly faster. The downside is that any security exploits against Mobile Safari now potentially allow worse things to happen than before.
[Update: And in fact, this is exactly how the still-in-progress WebKit2 framework is designed.]
In short, iOS was designed from the ground up to be more secure than Mac OS X. The price for this trade-off is performance.
Note too, that Nitro isn’t new. The WebKit team first announced it (then known as “SquirrelFish Extreme”) back in September 2008. That it took until now to show up at all on iOS is an indication of how complicated these security implications are. That Nitro’s availability on iOS is limited to Mobile Safari today does not imply that it will always be limited to Mobile Safari.
I’m actually not 100 percent sure that this is true for Android, but my understanding is that every app on Android is running in a JIT. That’s how the Dalvik virtual machine works — and the use of a JIT is the reason why recent versions of Android have performed significantly better than previous ones. I don’t see how they could be using a system-wide JIT if the Android OS disallowed processes from marking pages in memory as executable. But if I’m wrong about this, let me know. ↩︎