Full screen web apps fail to use Nitro acceleration in Apple's iOS 4.3

Full screen web applications launched via a Home screen icon on iOS devices run significantly slower than when launched directly within Apple's Mobile Safari browser on the same device, developers report.

According to a report by the Register, when a web app is saved to the Home screen in iOS 4.3, it performs about 2 to 2.5 times slower than when launched and run from that Home screen icon into full screen mode, compared with running the same web app within the browser.

This appears to be the case because the new Nitro JavaScript engine released as part of iOS 4.3 does not activate when launching full screen web apps saved as Home screen icons. (Full screen means the web browser user interface goes away, leaving a web app that is virtually indistinguishable from a native app; it is a feature unique to Apple's iOS).

Additionally, the report notes that "such 'home screen web apps' can't use various web caching systems, including the HTML5 Application Cache, which means they can't be cached to run offline. And they aren't rendered using Apple's newer 'asynchronous mode.' They're saddled with the old 'synchronous mode,' which means means they don't quite look as good."

Developers have filed bug reports about the issue, and have reported Apple is aware of the problem. In addition to web apps saved to the Home screen, the performance issues and limitations also affect native iOS free or paid apps listed in the App Store that use the UIWebView API to create an HTML app within a native app.

A tale of two browser processes

Investigation into the issue by Maximiliano Firtman, an author who writes about mobile web programming, notes that "Safari on iOS has an excellent feature that I still cant believe Android, Nokia or BlackBerry doesnt support yet. Using just some HTML and some JavaScript, you can suggest, or even force, a user to add the app to the Home Screen.

"When done, the user will receive an icon inside the home menu as any other native app installed. Using a second meta tag (apple-mobile-web-app-capable) you can force your web app to be opened in full-screen mode."

In full screen mode, web apps do not use the new Nitro engine, resulting in significantly slower performance as Firtman illustrates using SunSpider benchmarks, where Safari runs through code in 4.2 seconds compared to a full screen app that takes 10.2 seconds to complete (below).

However, Firtman notes that its not just a matter of Safari choosing to run any web apps launched from Home screen icons deliberately slower. He reports that full screen web apps (and native apps using UIWebView) use a different engine from Safari, reportedly an internal process called WebSheet.app.

The lack of support for Nitro within this separate browser process could possibly be related to security considerations or simply be a bug or evidence of a work in progress, as Nitro was just released as part of the new iOS 4.3.

Firtman also states, "Unfortunately, Safari on iOS and even UIWebView without Nitro, are the most powerful mobile HTML5 engines out there. I say 'unfortunately,' because I want Android, BlackBerry, Nokia, HP to reach Apples engine. Some are close, but Apple is still ahead. Even if we talk about full-screen web apps: Apple is the only platform supporting this feature."

A conspiracy theory launched

On the second page of its report, the Register admits, "Apple isn't degrading the speed of home screen web apps. It's boosting the speed of web apps in the browser."

However, the publication framed the issue as a conspiracy theory, with a headline that maintains the company has "handcuffed 'open' web apps." Purportedly, the publication says Apple is purposely handicapping web apps to push users to buy apps from its App Store, where the company makes a commission from app sales, as opposed to web apps, which don't pay Apple a cut but also don't use any resources within iTunes.

The Register prominently cited an unnamed "mobile web app developer" as saying "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," before admitting that the same problem also affects native apps that incorporate HTML.

If Apple were trying to force people to use the App Store, logically it wouldn't also purposely slow down apps in the App Store that use HTML internally. Additionally, it also wouldn't be working to accelerate web apps within the browser.

Further down the page, Alex Kessinger, a mobile app developer familiar who actually develops an App Store title, was cited by the Register as saying, "some people like to think of it as a conspiracy theory, but it could be a bug."

Two development platforms

Apple has long maintained that the iPhone, iPod touch and iPad support both the company's own native Cocoa Touch platform in apps that are only available for download through the App Store as well as the fully open HTML5 platform of the web, which Apple does not control.

"HTML5 is completely open and controlled by a standards committee, of which Apple is a member," Apple's chief executive Steve Jobs said of the web in his Thoughts on Flash.

This policy was completely opposite of the strategy Microsoft pursued in the 1990s, when the web first emerged. Microsoft saw the web as a threat to its dominant market position with Windows, and worked diligently to tie web development to native Windows APIs and to create non-standard web-related features that only worked within its own Internet Explorer browser.

For years, Microsoft's efforts prevented even simple Windows applications from being ported to the web. However, in the last decade a wide variety of tools and apps have migrated to the web, using its open, cross platform nature to reach users regardless of the hardware, operating system or browser they are using.

Rather than similarly viewing the web as a threat to its Cocoa Touch, Apple has embraced and led HTML5 development, and is recognized by third party developers such as Sencha as providing the best overall support for HTML5 standards in its mobile devices.

This has enabled Apple to maintain strict control over its native Cocoa Touch platform while allowing developers to bypass the company's infrastructure and take their apps to the web if they prefer to, leaving a relief valve for disgruntled mobile developers, pornographers, and hate speech proponents that Apple does not accommodate in the App Store.

Apple is also in a competitive race with Google, Mozilla and Microsoft to deliver the fastest HTML5 and JavaScript performance, making it difficult to imagine how the company would benefit from deliberately setting up an easy benchmark for failure in that regard just to distract attention away from simple mobile web games and other applets that have little to no impact on the record setting sales Apple has been experiencing with the App Store since opening it in 2008.

I can see how the "react first, think later” crowd will call this a purposeful on Apple’s part to force people to buy more apps, but it simply doesn’t make sense. However, it’s also unclear why Apple is using a newer versions of WebKit for Safari, and an older version for web apps and apps that access the WebKit framework.

PS: Mods, can we make an example of the two posters above me?

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

You have to laugh at the language usage in the title of this post. Seriously, "fail to use"? God forbid you ever blame Apple, for anything.

How would you have phrased it? That seems fairly strong to me. The only thing stronger I could see would be getting into speculation, like "Apple intentionally slows HTML apps" or something equally sensational. The simple fact is that the apps should use Nitro, and fail to. What's wrong with that?

This OS was written by developers who can't even get a simple clock app to work with daylight savings time. Even after multiple tries. I am thinking they simply forgot about homescreen webapps and HTML within Appstore apps and this is now sitting on someones to-do list. The conspiracy theories make no sense.

The Register prominently cited an unnamed "mobile web app developer" as saying "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," before admitting that the same problem also affects native apps that incorporate HTML.

Seriously, why would Apple deliberately handicap their own devices? This is a bug, plain and simple. Clearly, Mobile Safari received the upgrade love, but the other app (WebSheet.app) didn't. Easy for them to fix this.

How would you have phrased it? That seems fairly strong to me. The only thing stronger I could see would be getting into speculation, like "Apple intentionally slows HTML apps" or something equally sensational. The simple fact is that the apps should use Nitro, and fail to. What's wrong with that?

Just ignore him. Ireland is an old troll with an avowed hatred of the author of this article that he mentions as often as he can.

Needless to say, like all biases, this clouds his thinking and leads him to assume, and also see things that are not actually in evidence.

<obscure reference> I'd hate to live anywhere near him if a Flying Saucer turned off all the lights in our neighbourhood. </obscure reference>

You have to laugh at the language usage in the title of this post. Seriously, "fail to use"? God forbid you ever blame Apple, for anything.

What's the benefit of throwing blame around? Web apps are not independent applications. They use Apple's web framework, so this is Apple's fault, but the purpose of neither the article or the headline is to point fingers and laugh like you clearly want to.

In thinking about this, I think there is a distinct difference between a "web view" and a full-blown browser that incorporates a web view. A browser can bring benefits like hardware acceleration to web views. Can web views (within a native application) do that on their own? Does hardware acceleration fit in to the web view layer or the browser/application layer? Just the programmer in me suggesting that maybe this isn't a bug per-se. But then there's the discussion of JavaScript, which does belong side-by-side with the web view and should be just as fast no matter what. Hmmm.

How would you have phrased it? That seems fairly strong to me. The only thing stronger I could see would be getting into speculation, like "Apple intentionally slows HTML apps" or something equally sensational.

The surprising thing here is that this article is well written relative to the crap seen in other forums.

Quote:

The simple fact is that the apps should use Nitro, and fail to. What's wrong with that?

However it appears that you did not read the article. Please try again.

I'm not saying it wouldn't be a bad idea to use Nitro and the new web kit but there is a clear reason why that hasn't happened. Basically Apple will need to either overhaul UIWebView to use the latest WebKit/Nitro or back port functionality. This is not a minor effort and would likely require holding off till the 5.0 release.

There really is nothing to complain about here, we are fortunate to get the Safari/Nitro update. If it wasn't for this update people wouldn't even notice the difference.

I'm not saying it wouldn't be a bad idea to use Nitro and the new web kit but there is a clear reason why that hasn't happened. Basically Apple will need to either overhaul UIWebView to use the latest WebKit/Nitro or back port functionality. This is not a minor effort and would likely require holding off till the 5.0 release.

There really is nothing to complain about here, we are fortunate to get the Safari/Nitro update. If it wasn't for this update people wouldn't even notice the difference.

It does seem odd that wed get this much of a webkit.framework overhaul with a point update. Id think moving to WebKit2 and Nitro would be an iOS 5.0 feature, but maybe they wanted it for the iPad 2 knowing that it would be compared to other mobile devices.

Im surprised its doing so well against Googles V8 when this was the one area in which Google has the most direct reason to make their JS the best. Even the original iPad with iOS 4.3 is doing great against Android 3.0 in JS tests, which is impressive considering the HW compared to the Xoom.

Are there really two WebKit frameworks in iOS 4.3 or is there something else at work here? Why is it good enough for Safari, but not for web apps and in-app browsing, which I thought connected to the same framework? So what does that mean for iOS 5.0s feature list?

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

Right now Apple still needs the web browser in iOS because apps can't cover everything in the web. But there's no reason why Apple would need web apps, it's just a back-door way for companies to avoid paying Apple the 30% cut. I could see Apple totally banning web apps, and they're not doing it yet only because they're worried about the PR hit they'd get if they did that.

I think it is ABSURD that Apple is not back-porting improvements like Nitro to ALL iOS devices, even the first generation. Apple had a standard of providing Safari, QuickTime, iTunes and Security updates to older Mac OS X system versions for the last two iterations! Sucks that they are not continuing that great tradition.

Quote:

Originally Posted by solipsism

It does seem odd that wed get this much of a webkit.framework overhaul with a point update. Id think moving to WebKit2 and Nitro would be an iOS 5.0 feature, but maybe they wanted it for the iPad 2 knowing that it would be compared to other mobile devices.

Im surprised its doing so well against Googles V8 when this was the one area in which Google has the most direct reason to make their JS the best. Even the original iPad with iOS 4.3 is doing great against Android 3.0 in JS tests, which is impressive considering the HW compared to the Xoom.

Are there really two WebKit frameworks in iOS 4.3 or is there something else at work here? Why is it good enough for Safari, but not for web apps and in-app browsing, which I thought connected to the same framework? So what does that mean for iOS 5.0s feature list?

The surprising thing here is that this article is well written relative to the crap seen in other forums.

However it appears that you did not read the article. Please try again.

I'm not saying it wouldn't be a bad idea to use Nitro and the new web kit but there is a clear reason why that hasn't happened. Basically Apple will need to either overhaul UIWebView to use the latest WebKit/Nitro or back port functionality. This is not a minor effort and would likely require holding off till the 5.0 release.

There really is nothing to complain about here, we are fortunate to get the Safari/Nitro update. If it wasn't for this update people wouldn't even notice the difference.

Oh ohh, somebody is actually paying attention. You are giving the internet a bad name Mr Wiz.

Javascript engine tweaking is a battleground right now and the Safari group are working wonders. I suspect the integration of Nitro into the web view kit will be the responsibility of the iOS group who will have a somewhat different agenda and timetable - and testing requirement. One has to take the sarcastic fuckers at the Register with a pinch of salt. In the UK they would be known as "wind-up merchants". Its their schtick (to mix up the ethnic slang}

They've said from the beginning that they would only give official software updates to iOS devices for two years. Its clear that the hardware in the original iPhone and the iPhone 3G are not up to the task of newer iOS updates.

Quote:

Originally Posted by libertyforall

I think it is ABSURD that Apple is not back-porting improvements like Nitro to ALL iOS devices, even the first generation. Apple had a standard of providing Safari, QuickTime, iTunes and Security updates to older Mac OS X system versions for the last two iterations! Sucks that they are not continuing that great tradition.

I thought it was three years. Besides, where did I say iOS updates, I am talking about app and framework updates which have been done on Mac OS X WITHOUT a full OS update!!!

Quote:

Originally Posted by TenoBell

They've said from the beginning that they would only give official software updates to iOS devices for two years. Its clear that the hardware in the original iPhone and the iPhone 3G are not up to the task of newer iOS updates.

I thought it was three years. Besides, where did I say iOS updates, I am talking about app and framework updates which have been done on Mac OS X WITHOUT a full OS update!!!

1) They never said 3 years.

2) Your comment "I think it is ABSURD that Apple is not back-porting improvements like Nitro to ALL iOS devices, even the first generation. clearly states iOS.

3) Youre inventing a problem just to be an ass or you have an inability to see how a desktop OS that has separate OS updates from app updates, is different from iOS, which updates the entire OS each time, even if its just for bug fixes.

4) You havent made a single compelling argument as to why Safari, Quicktime and the iTunes app on iOS should be updated independently of the OS and why even iOS 1.0* (the 1st generation, as you put it) should be getting these updates separately from the rest of the OS.

* This is where you say that you meant the 1st generation of the iPhone, not the OS, but to argue that point youd have to admit that there is a different dynamic involved when you are compared a desktop OS and separate app updates to mobile devices.

Dick Applebaum on whether the iPad is a personal computer: "BTW, I am posting this from my iPad pc while sitting on the throne... personal enough for you?"

They've said from the beginning that they would only give official software updates to iOS devices for two years. Its clear that the hardware in the original iPhone and the iPhone 3G are not up to the task of newer iOS updates.

That being said, I'm one of the unfortunate who bought a 3G just prior to the release of the 3GS and am still under my original 2 year contract. Using your logic, I should still be receiving official software updates. I do agree, however, with the second part of your quote. My 3G has been extremely crashy since the v.4 "upgrades."

That is unfortunate. I have a friend who just bought an iPhone. I told her she should have checked with me. We are a couple of months out from the iPhone 5. She might as well have waited.

At this point they can no longer support the iPhone 3G. Soon we'll have dual core 1GHz phones, the software has moved on.

Quote:

Originally Posted by jcraig

That being said, I'm one of the unfortunate who bought a 3G just prior to the release of the 3GS and am still under my original 2 year contract. Using your logic, I should still be receiving official software updates.