This link at mobilexweb.com shows the evidence. Here is the SunSpider test standalone, showing a time of 4098ms, and pinned to the home screen as an app, where it shows 10391.9ms:
The consequence: apps created using WebKit as a runtime, for example using PhoneGap, will not get the benefit of Nitro.
It would be easy to conclude that Apple is deliberately hobbling these apps in order to protect native apps, which can only be installed via Apple’s App Store and are subject to its 30% cut. However that might not be the case. It could be a bug – according to Hacker News it has been reported as such:
To add another note to this, its a bug that Apple seems to know about. I can’t link to it because its marked CONFIDENTIAL across the top of the dev forums, but in short its known about and being investigated.
or it could be a security feature. Using a just-in-time compiler exposes the operating system more than just interpreting the code; perhaps Safari has more protection when running standalone.
Either way, with the increasing interest in WebKit as a de facto cross-platform application runtime for mobile, this particular limitation is unfortunate.
Update: There are also reports of the HTML 5 offline cache not working other than in full Safari:
I’ve tested this by switching apple-mobile-web-app-capable from ‘yes’ to ‘no’ and offline cache works as expected. But whenever it’s switched back to ‘yes’, it’s not working anymore. This occurs when the app is standalone at home screen. As a website, viewed with Safari cache is working as expected.
- Google Chrome usage growing fast; Apple ahead on mobile web
- Local SQL support in Safari vs Google Gears: what is happening?