Confirmed: some Web apps not seeing iOS 4.3 JavaScript speedup

The JavaScript performance improvements that accompany iOS 4.3—boosting raw performance as much as 2.5x—don’t appear to carry over to in-app browsers or Web apps saved to the home screen. Another bug appears to prevent Web apps saved to the home screen from properly using HTML5 caching for offline use or using asynchronous loading. While these issues may be bugs and have been reported to Apple, some developers believe it is a conspiracy to make Web apps perform worse than native apps, pushing developers towards the App Store. However, the issues could just as likely be technical problems as any concerted effort from Apple to put the squeeze on Web developers.

To understand the JavaScript performance problem, it’s helpful to understand the major performance improvement Apple brought to MobileSafari’s Nitro JavaScript engine. Using a technique called just-in-time compilation, the engine converts JavaScript code into native ARM machine code. The engine then changes the area in memory where the native code is stored from writeable (for data storage) to executable (for code) to run the code directly.

This dynamic code generation and execution is much faster than the previous JavaScript engine used in iOS 4.2. Using the SunSpider JS benchmark, MobileSafari took 10,278 milliseconds when we ran the test on iOS 4.2. On iOS 4.3, however, it ran in just 4,064ms—in other words, about 2.5 times faster.

By default, however, iOS doesn’t allow execution of dynamically generated native code stored in writeable memory. This is a security feature, as overwriting memory with code and executing it is a common malware attack vector. But iOS doesn’t prevent it from happening wholesale—permission to change memory space from writeable to executable can be enabled on a per-app basis, and it appears that permission has so far only been granted to MobileSafari.

Apps that include an embedded browser using UIWebView don’t appear to have permission to execute code stored in writeable memory, so JavaScript runs at the same speed as it did in iOS 4.2. A similar issue exists for full-screen Web apps saved to the iOS SpringBoard. Those apps are opened and executed by WebSheet.app, not MobileSafari itself.

(We verified this by running various JavaScript benchmarks natively, as a saved Web app, and via Twitter’s in-app browser. The benchmarks run via in-app browsers and via a Web app saved to the SpringBoard ran about as fast as they did on iOS 4.2.)

“It seems that people are attributing to malice what can easily be explained by history—iOS has never allowed user code to generate code on demand, and this has for years prevented JIT compilation from taking place,” Miguel de Icaza, one of the lead developers behind both GNOME and Mono, told Ars. “So far, debuggers and Safari both get to use this functionality and they both get the special flag that lets them turn writable [memory] pages into executable pages. Third parties have never been able to get access to this—not Mono, not Java, not Lua, not JavaScript, or any other runtime, compiler, or library that generates native code dynamically.”

Effectively, Web-based apps that don’t run directly in MobileSafari don’t perform slower than they did on iOS 4.2; they just don’t perform any faster. However, other issues appear to affect the performance of full-screen Web apps besides the JavaScript execution speed. One is that HTML5 caching currently doesn’t work properly in iOS 4.3. Web apps can use local caching that enables apps downloaded from the Web to continue to run offline. A bug in iOS 4.3 prevents these apps from running offline, even when the resources are cached properly.