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

Posted:
in iPhone edited January 2014
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 can?t believe Android, Nokia or BlackBerry doesn?t 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 Apple?s 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.
«1

Comments

  • Reply 1 of 33
    solipsismsolipsism Posts: 25,726member
    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?
  • Reply 2 of 33
    ghostface147ghostface147 Posts: 1,629member
    Conspiracy!
  • Reply 3 of 33
    pokepoke Posts: 506member
    The Register is basically a tech tabloid and they never miss an opportunity to take a shot at Apple. It sounds like it's probably just a bug.
  • Reply 4 of 33
    irelandireland Posts: 17,534member
    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.



    Quote:

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



  • Reply 5 of 33
    brookstbrookst Posts: 62member
    Quote:
    Originally Posted by Ireland View Post


    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?
  • Reply 6 of 33
    christophbchristophb Posts: 1,438member
    Quote:
    Originally Posted by solipsism View Post




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



    Sheesh! We all can't be first and second!
  • Reply 7 of 33
    Quote:
    Originally Posted by ChristophB View Post


    Sheesh! We all can't be first and second!



    Yeah, let 'em waste their 15 minutes however they want.
  • Reply 8 of 33
    aiaddictaiaddict Posts: 487member
    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.
  • Reply 9 of 33
    bulk001bulk001 Posts: 434member
    Quote:
    Originally Posted by solipsism View Post


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



    Facing the wrath of solipsism is surely example enough!
  • Reply 10 of 33
    coolfactorcoolfactor Posts: 1,371member
    Quote:

    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.
  • Reply 11 of 33
    Quote:
    Originally Posted by BrooksT View Post


    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>
  • Reply 12 of 33
    Quote:
    Originally Posted by [email protected] View Post


    Yeah, let 'em waste their 15 minutes however they want.



    Yeah, everyone should just do whatever they want, anytime they want. That'll work.
  • Reply 13 of 33
    coolfactorcoolfactor Posts: 1,371member
    Quote:
    Originally Posted by Ireland View Post


    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.
  • Reply 14 of 33
    coolfactorcoolfactor Posts: 1,371member
    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.
  • Reply 15 of 33
    SpamSandwichSpamSandwich Posts: 30,581member
    Quote:
    Originally Posted by Prof. Peabody View Post


    Yeah, everyone should just do whatever they want, anytime they want. That'll work.



    I agree. First a warning, then a ban, perhaps? Mods? Your take?
  • Reply 16 of 33
    wizard69wizard69 Posts: 12,668member
    Quote:
    Originally Posted by BrooksT View Post


    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.
  • Reply 17 of 33
    addaboxaddabox Posts: 12,660member
    Nineteenth!
  • Reply 18 of 33
    solipsismsolipsism Posts: 25,726member
    Quote:
    Originally Posted by wizard69 View Post


    This is only a 4.x release, we are lucky to get Safari with Nitro.



    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 we?d get this much of a webkit.framework overhaul with a point update. I?d 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.



    I?m surprised it?s doing so well against Google?s 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.0?s feature list?
  • Reply 19 of 33
    sflocalsflocal Posts: 4,399member
    Quote:
    Originally Posted by Prof. Peabody View Post


    Yeah, everyone should just do whatever they want, anytime they want. That'll work.



    Seems to work perfectly for Android right???

    Oh... wait...

    </sarcasm>
  • Reply 20 of 33
    That declares "Fukushima is a triumph for nuke power: Build more reactors now!"
Sign In or Register to comment.