UIWebView
Latest
Apple approves JavaScript iOS games that don't use a browser
Look Ma, no WebKit! Your inner geek and nerd should give each other a little hug this morning as you read about the latest rather cool accomplishment of Dominic Szablewski, creator of the Impact JavaScript HTML 5 game engine. He's just released two free games, Biolab Disaster and Drop, which are not, as Szablewski says, the first JavaScript games to be released in the App Store. "Tools like PhoneGap or Titanium make it easy to bundle some HTML pages and JavaScript together in an app and display them in a UIWebView, which is basically just a browser window," he says. However, his games are different because they don't use a browser window to display them. "They don't use PhoneGap or Titanium. They don't even use a UIWebView. Instead, they bypass the iPhone's browser altogether and use Apple's JavaScript interpreter (JavaScriptCore) directly. All graphics are rendered with OpenGL instead of in a browser window and all sound and music is played back with OpenAL," Szablewski says. What Szablewski has done wasn't particularly easy, and as games, his offerings aren't up there with Angry Birds. But his work could open the way for other developers to write more apps with a minimum of fuss. Read his blog for full details of the process.
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]
Android vs. iPhone in 'flawed' mobile browser performance test
Post edited to clarify that the browser testing is not representative of Safari performance, and included Blaze response to CNET. –Ed. Blaze Software, a Canadian software company, today released the results of what it calls a "definitive" research effort to discover "which [mobile] browser is really faster from a user's point of view." The study concluded that Android's browser is 52% faster than the iPhone's. Before you trade in your iPhone for a device powered by Android, The Loop suggests Blaze's study is "flawed." According to its report, Blaze's testing methodology relied on "custom apps, which use the platform's embedded browser. This means WebView (based on Chrome) for Android, and UIWebView (based on Safari) for iPhone." As we've been hearing from developers of iPhone web apps over the past few weeks, Apple's improvements to the Mobile Safari JavaScript engine and other rendering speedups have not been extended to the internal browser tool used by apps, nor to standalone web apps that are pinned as icons to the home screen. It's not yet completely clear if or when the Safari performance boost will make it to the embedded browser view; John Gruber cites some security-related concerns that may be involved. The tests don't reflect performance of the official web browsers included with each platform. UIWebView did not include this performance boost; it may be "disingenuous" to conclude Android beat Safari, according to The Loop. Using an embedded browser is not the same as using the official browser where customers spend the most time interacting with websites. "Obviously someone is looking to make a mountain out of a molehill," Gartner analyst Michael Gartenberg told The Loop. "It's not an apples to apples test." Apple's Natalie Kerris was equally dismissive, speaking to CNET: "Their testing is flawed. They didn't actually test the Safari browser on the iPhone. Instead they only tested their own proprietary app, which uses an embedded Web viewer that doesn't actually take advantage of Safari's Web performance optimizations." Kerris also noted that even without the true Safari match-up, the testing only showed about a second of difference browsing pages. Blaze's CTO Guy Podjarny admitted to CNET that the testing methodology made an invalid assumption that the embedded browsers would work as fast as Safari: "This test leveraged the embedded browser which is the only available option for iPhone applications. Blaze was under the assumption that Apple would apply the same updates to their embedded browser as they would their regular browser. If this is not the case and according to Apple's response, it's certainly possible the embedded browser might produce different results. If Apple decides to apply their optimizations across their embedded browser as well, then we would be more than willing to create a new report with the new performance results." Even so, the results of Blaze's research should still disappoint Apple's fans. Apple touted significant web technology performance gains in its latest iOS release. It seems reasonable to expect these gains to appear simultaneously in both the Safari browser and the underlying UIWebView framework used in nearly any app that relies on web technologies like JavaScript. Blaze's researchers built custom apps to compare the iPhone 4 and Google Nexus S using websites from Fortune 1000 companies. Each site included in the test was loaded multiple times over several days using a Wi-Fi connection. The final results reflect a median benchmark from over 45,000 page loads. "Android 2.3 was 52% faster than iPhone 4.3, with a median load time of 2.144 seconds vs. iPhone's median load time of 3.254 seconds," Blaze reports on its blog, adding, "Android was faster than iPhone in 84% of the tested websites, and iPhone beat Android in 16% of the races. Android...provided a faster browsing experience 4 times out of 5."
