iOS 5 finally brings Nitro JavaScript speed to home screen Web apps

Web apps saved to a user's home screen will run as fast as they do in Mobile …

Chris Foresman – Jun 17, 2011 2:28 pm | 70

Apple brought huge JavaScript performance improvements to Mobile Safari in March of this year, but those benefits didn't extend to Web apps saved to a user's home screen. iOS 5 will remedy that situation, however, finally putting home-screen Web apps on equal performance footing with those that run in the browser.

Apple brought its Nitro JavaScript engine to Mobile Safari as part of iOS 4.3. Nitro uses just-in-time compilation to dynamically convert interpreted JavaScript code into compiled native ARM code that runs as much as 2.5 times faster than interpreted code. The engine then changes the area in the memory where the native code is stored from writeable (for data storage) to executable (for code) to run the code directly.

Since Web-based applications rely heavily on JavaScript, Web apps running from within Mobile Safari got a significant speed boost form this improvement. Web apps saved to the home screen for direct access, however, did not. Those apps run in a separate process called Web.app, which wasn't able to take advantage of the Nitro engine.

Some speculated that Apple had done this deliberately to make Web apps seem like they perform worse than native apps. However, the difference ended up being credited to iOS's security model, which requires that executable code be digitally signed by the developer and verified by Apple.

"The way code signing works on the iPhone is that only pages [in memory] that come from signed applications can be executable," Charlie Miller, principle research consultant at Accuvant and iOS security expert, told Ars. "If an app tries to make a writeable page executable, it cannot. However, for JIT, this is exactly what you'd like to do."

Apple made a special exception for Mobile Safari to enable Nitro JIT compilation. In other words, Safari has special permission to generate code dynamically within protected memory and have that code executed by a device's CPU. In iOS 4.3 and higher, Web.app doesn't have the same permission. In iOS 5, though, it does. So, once iOS 5 is released to the public, all the Web apps that you have saved as icons on your home screen will run as fast as they do within Mobile Safari itself.

One caveat, though, is that third-party apps that load webpages in a WebKit view still won't take advantage of Nitro's fast JIT execution. Again, security is the main concern.

"The reason I think Apple hasn't allowed dynamic code injection in third-party apps is that allowing dynamic code injection in third-party apps doesn't just allow Nitro to work, it allows any code injection mechanism to work," Graham Lee, iOS app security consultant, told Ars. "That's a dangerous proposition: especially if the generated code is created as a result of parsing untrusted input from an unknown provider on the Internet."

Such code injection is how security holes are exploited by malicious software to do Very Bad Things™, such as access your data without permission, or capture sensitive information like credit card numbers or bank account passwords.

But why would Apple let such dynamically generated code run within Safari itself, as well as Web.app processes, if that code could result in a security breach for users? The answer is likely that Apple controls all the code in Mobile Safari and Web.app, and it can ensure code injection doesn't get outside iOS's application sandboxes.

"We have to assume that Apple is willing to take the risk when it comes to Web.app, Lee said. "Apple can, and probably does, perform a full security audit on the source for Web.app, in addition to other security testing, including Nitro itself. Therefore they understand the risk of permitting dynamic code insertion in a way that they can't know for third-party apps."

If problems are discovered in the field, Apple is also in a position to push out security updates to plug any holes. Paired with iOS 5's OTA "delta" update capability, it's possible to minimize the risk in a relatively short period of time. With third-party apps, on the other hand, there's no guarantee the developer would even notify Apple if a security issue was discovered. In any event, the only option Apple would have is to pull the app in question if a problem is discovered—not necessarily a great option for the developers of such apps nor their users.

Ultimately, most users won't know the subtleties of security models or the risks associated with dynamic code generation. But, giving Web.app the ability to run JavaScript using Nitro represents a good compromise between potential security risks and known user benefits.