browser-gate
Latest
Apple confirms some WebKit optimizations unavailable to iOS Apps
The web performance enhancements included in Apple's latest mobile operating system, iOS 4.3, are exclusively available to the Mobile Safari web browser, an Apple spokesperson has confirmed. The optimizations, which double JavaScript performance in Mobile Safari, are not available to the underlying web view framework that powers the embedded browsers in other apps. "The embedded web viewer does not take advantage of Safari's web performance optimizations," Trudy Muller, a spokesperson for Apple, told The Register. Apple's statement comes as a response to controversy started earlier this week when developers first recognized the notable performance gap between Mobile Safari and the embedded web views in their own applications. The debate deepened yesterday when Blaze Software released the results of a study that implied Android loaded web pages 52 percent faster than the iPhone 4. Apple refuted Blaze's results, citing the differences between Safari and the embedded web viewer. Many developers voiced concerns about Apple's decision to exclude third-party apps from taking advantage of the Nitro JavaScript engine included in iOS 4.3. One anonymous developer suggested Apple purposefully omitted the enhancements to subtly degrade the web experience in non-Apple browsers and web apps launched from the home screen. "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," the developer claimed in The Register. Matt Asay, vice president of business development for Strobe, indicated that Apple filed the performance gap as a bug but marked it "not to be fixed by exec order." On Twitter, Asay called the scenario "slimy" and suggested it's partly a tactic for convincing developers to focus on the development of native apps. The real reasons for the performance gap may not be so sordid. Ars Technica observes the Nitro JavaScript engine uses a technique called "just-in-time [JIT] compilation" to transform dynamic JavaScript code into machine code optimized for the ARM processor architecture. Nitro's ability to dynamically generate and execute code enables it to process JavaScript much faster than its predecessors. Unfortunately, for security reasons, other applications developed for iOS aren't typically granted permission to execute dynamically generated native code. Miguel de Icaza, a lead developer for both GNOME and Mono, said he suspects the issues are legitimate technical problems and not a conspiracy. "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," Icaza told Ars Technica. "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." As a result, applications that use the UIWebView framework, including web apps launched from the home screen, will not enjoy the performance optimizations available to Apple's Mobile Safari web browser. Despite the technical challenges in adapting Nitro to work safely within the UIWebView framework, developers like Icaza are optimistic Apple will enable the new JavaScript engine for apps with embedded web views. "Since this is the first OS release with Nitro on the Mobile Safari browser, it is probably safe to assume that this is merely a bug or limitation," he said. Is this a conspiracy worth dubbing "browser-gate," or simply a small speed bump in this tale of two JavaScript rendering engines? Please use the comments below to discuss. [via The Mac Observer]
