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]
Share
The web performance enhancements included in Apple's latest mobile operating system, iOS 4.3, are exclusively available to the Mobile...
Add a Comment
When did -gate become a suffix? It's not even the full word of the conspiracy for which it was named - it's just a syllable. Stupid 70's. I suppose you could call it 'java-gate' but it sounds like a way of administering brown liquid.
Good article though, sheds light on the deal.
Isn't this kind of behavior (keeping "special" APIs to themselves so competing applications can't actually compete) what got Microsoft into trouble with the government?
March 19 2011 at 9:51 PM Report abuse Permalink rate up rate down ReplyAm I the only one who finds Safari practically useless on my iPhone unless I'm visiting a page formatted specifically for mobile phones?
March 19 2011 at 12:36 PM Report abuse Permalink rate up rate down ReplyThis doesn't adequately explain why web clips are used by UIWebView instead of Safari. Apple has full control over what runs a web clip.
If Apple wants us to believe that they are not out to marginalize web apps, all they need do is make sure that web clips are used only by Safari, not UIWebView.
Until that gets done, the conspiracy theorists will still have a viable point of contention.
The mobile Safari web browser offers a full user interface (UI) for editing the URL, saving bookmarks, navigating the browser history, and much more. Web clips saved to the home screen launch in a separate system level app, called "WebSheet," that does not have Safari's UI. WebSheet also responds to special meta tags that web app developers can use to customize some of iOS's system UI (like the color of the carrier bar at the top of the screen). WebSheet may also contain other programatic features under the hood not available to Safari.
Why?
Think of Dashboard Widgets on Mac OS X. Mac OS X renders Dashboard Widgets with the same WebKit rendering engine as Safari for Mac. In fact, if you crack open the package contents of a Widget, you can often run it using Safari. But it makes perfect sense for Dashboard Widgets to run without forcing users to launch the full Safari web browser.
The WebSheet app is, in many ways, the iOS equivalent of Mac OS X's Dashboard. WebSheet allows mobile web applications designed to be launched from the home screen to run independently of the mobile Safari web browser. Imagine opening a web app from the home screen and having to deal with "tab management" in Safari or being offered a full UI for entering an unrelated URL. And users certainly don't need to bookmark a web app launched from the home screen! In iOS 4.3, a web app may see better performance by running in mobile Safari, but users would be forced to contend with extra UI irrelevant to the application.
I am sure Apple could re-write Safari to allow web apps to hide the browser UI, but it's probably not as simple as it sounds. Safari would have to be written to hide its UI for only web clips launched from the home screen. Otherwise, if Safari's UI could be completely hidden by a regular website, nefarious coders could exploit the browser for phishing attacks, replacing Safari's UI with their own that soothes users into providing sensitive personal data. WebSheet, like Dashboard, may also have different permissions to access the other apps and data on your mobile device while websites in Safari are secured in a programatic sandbox. Perhaps Safari's performance would suffer if it were saddled with the extra security features necessary to safely run web clips alongside normal websites.
Personally, I prefer sacrificing a bit of performance to experience web apps launched from the home screen securely and as intended by the developer. It makes sense to continue running web clips outside of mobile Safari. Like Icaza, I imagine Safari's performance gains will one day become available to all iOS apps with an embedded web view, including WebSheet. For now, I accept the explanation for the differences between Safari and the embedded web view, not out of a blind devotion to Apple, but because, as a developer myself, I understand the time constraints and feature prioritization necessary to deploy software to market.
heh. Logic doesn't enter into it. Conspiracy theorists don't need a viable point of contention to be conspiracy theorists.
March 20 2011 at 1:09 PM Report abuse Permalink rate up rate down ReplyConspiracy theories for things like this sound idiotic. Apple's history of explanations for their decisions has always been that they put the "user experience" above most anything else. It would completely contrary to their M.O. that they would actively degrade the user experience just to protect their corporate ego or something.
March 19 2011 at 11:37 AM Report abuse Permalink rate up rate down ReplyYou are oversimplifying things. Allowing third-party applications to use the JIT engine could open the door for exploits that cause carefully crafted JavaScript code to generate unprivileged native ARM code that breaks itself out of the sandbox available to JavaScript code and goes around every security measure in place for Javascript code. Because you only need to surf to a website with said JavaScript code on it, it would be a huge hole for drive-by exploits.
By restricting JIT to Safari only, all third-party applications using UIWebView basically have an additional and pretty strong extra layer of security between JavaScript and the CPU and RAM in your phone: the JavaScript interpreter. Safari itself, in the mean time, is likely designed and programmed extremely defensively, with the JIT engine running in some kind of fenced-off semi-virtualized sandbox that restricts CPU and addressable RAM at the hardware level, which requires very specific and intrusive OS facilities that only Apple applications have access to. Porting UIWebView over to have the necessary lowest-level restrictions for any app embedding the component really is non-trivial.
It will probably come in an update.
FInally, someone who gets it! Apple isn't only allowing the Javascript enhancements in Safari because they want all other webkit-using browsers to look bad compared to it, but because Safari is the only application they trust to handle security concerns correctly at this point because they're the ones who wrote it. I imagine once they're able to build more security features right into Nitro and Webkit it'll be open to all browsers as well.
March 19 2011 at 10:03 AM Report abuse Permalink rate up rate down ReplyI see the point with restricting UIWebView (for now), bot I don't see any point at all why pages saved to the home screen should be limited. I thought they just worked like safari webapps.
March 19 2011 at 2:54 PM Report abuse Permalink rate up rate down Reply"iOS has never allowed user code to generate code on demand [...] Third parties have never been able to get access to this"
Not a valid argument. We're not talking about third parties generating code on demand and having access to it, we're talking about third parties using official iOS-APIs and the completely opaque UIWebView. Executing Javascript in an UIWebView wasn't a security problem before, so it shouldn't be a security problem now.
Ahhh, so it was definitely UIWebView like I originally thought. Well it's partially conspiracy, I would say. Apple is trying to prevent other browsers from gaining momentum (Opera Mobile, etc). Except that the normal (and major) browsers are more likely going to be implementing their own systems I believe for rendering the Web's content.
It's too bad though that the UIWebView couldn't be given the functionality since I believe that many applications, even full-scale (and popular) ones, use the framework for simple things, like contacting support or for about pages (loading local html files, etc). Interesting.
What momentum? Apple has already completely halted momentum of third-party native browsers on iOS. None are allowed. The only way Opera was able to get theirs on was by rendering pages remotely and sending them back, compressed, to your device.
If you're talking about apps that use the default webkit webview, they did nothing to harm those apps. One, they added faster js to safari only. Didn't decrease performance of the existing webview. Two, the examples of local caches files and about pages are hardly intense js scripts that would really take advantage of nitro anyhow.
Safari gets a bit faster, UIWebView stays the same. The overall situation is better than before, not worse. Nothing to complain about.
March 18 2011 at 11:43 PM Report abuse Permalink rate up rate down ReplyGruber said the same thing. (http://daringfireball.net/2011/03/nitro_ios_43)
I know people want to make a political issue out of it, but it's a technical one. Maybe once webkit2 gets ported over to iOS and the content is running in a separate process from the UI we'll see the speedup everywhere.
Deals of the Day
more deals- Refurb Mac Pro Xeon Quad-Core 2.8GHz Workstation for $1,150 + $38 s&h, more
- Used Apple iPad 32GB Wi-Fi Tablet for $200 + free shipping
- Apple iPod nano Multi-Touch 8GB MP3 Player for $100 + $8 s&h
- Cases for New iPad at HandHeldItems: Extra 20% off, $2 credit, from $3 + $3 s&h
- $15 Apple iTunes Gift Card for $8 for new Saveology customers
- Retro 80's Case for iPhone for $11 + $2 s&h
Software Updates
more updatesFeatured Stories
more stories
Popular Stories
TUAW (or The Unofficial Apple Weblog) is a website devoted to tips, reviews, news, analysis and opinion on everything Apple.
18 Comments