Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Performance of Web Apps Saved to Home Screen Hampered in iOS 4.3
- Thread starter MacRumors
- Start date
- Sort by reaction score
I was thinking about that right after I posed my reply.Except for the fact that any external links open in Safari and not within the web app.
EDIT: It looks like they had to have made a custom Configuration Profile using the iPhone Configuration Utility to get the web clip to work
Last edited:
Sensationalist bogus headline
Web apps are accelerated in OS 4.3, not hampered.
They just don't get all the speedups that are incompatible with the current iOS app security sandbox.
Safari runs outside the regular security sandbox, so it can do things that aren't allowed for any other webkit instances, even web clippings. Such things as spawning accelerated processes or jumping into executable code. This must mean that currently Apple only knows sort-of how to protect 1 webkit instance (and not very well, given the security loophole contest currently in the news). Why open up even more ways to steal your data and bot your iDevice?
Web apps are accelerated in OS 4.3, not hampered.
They just don't get all the speedups that are incompatible with the current iOS app security sandbox.
Safari runs outside the regular security sandbox, so it can do things that aren't allowed for any other webkit instances, even web clippings. Such things as spawning accelerated processes or jumping into executable code. This must mean that currently Apple only knows sort-of how to protect 1 webkit instance (and not very well, given the security loophole contest currently in the news). Why open up even more ways to steal your data and bot your iDevice?
Can't confirm any of this FUD
Running the SunSpider benchmark on a iPhone 3GS, directly in the browser and from the homescreen delivered similar results (around 5200).
The HTML5 caching seems to work fine, in my own apps...
It has always been necessary to open a webapp added to the homescreen once before the HTML5 caching kicked in. So if you test this, test it properly. Add the app to the homescreen, open it from the homescreen, close it. Switch on airplane mode, restart if you really want to be sure, and open the app. For me it works fine.
Running the SunSpider benchmark on a iPhone 3GS, directly in the browser and from the homescreen delivered similar results (around 5200).
The HTML5 caching seems to work fine, in my own apps...
It has always been necessary to open a webapp added to the homescreen once before the HTML5 caching kicked in. So if you test this, test it properly. Add the app to the homescreen, open it from the homescreen, close it. Switch on airplane mode, restart if you really want to be sure, and open the app. For me it works fine.
I'm quite sure this is intentional. Web apps are the one thing that might actually circumvent some of the App Store limitations.
"Android does web apps better!" Not much of a marketing slogan now, is it? The whole concept is too complicated to matter to most of the people who buy these things. It's not interesting enough to become a big deal. I mean, the whole Antennagate thing did absolutely nothing to Apple's sales, why would people care about something as trivial as this?
Basically the only people this matters to are specs enthusiasts and developers and developers are Apple's target.
People have to realise there is absolutely no other motivation for Apple to do anything except money. That's why we have non-user replaceable batteries in laptops (buy a new computer, not a battery) and that's why we can't have subscriptions outside of the App Store (except at the publisher's expense). The fact that their customer support and the experience of basic operations on the devices is better than their competition is their business model, not because they think it's good for mankind.
Yes, exactly.
People don't seem to understand how complex the interactions between UIWebView, WebKit and native application code can be. A lot of things could (and likely would) break if Apple upgraded the system-wide WebKit as they did for Safari. Nitro's speed requires it to do some crazy low-level tricks to compile JS code; performing these tricks in the context of other apps that weren't designed around it opens up potential issues in
- Binary compatability
- Threading issues (moving to asynchronous redrawing)
- Security sandboxing
to name a few.
It's one thing to make these sorts of changes to the WebKit library when it is only running within their own app, that has itself been revised alongside WebKit, and in which Apple is quite confident about it's overall solidness.
It's quite another thing to let other untested, native applications interact with it. That's just begging for bugs, crashes and potential exploits.
Apple made the sane, conservative choice to avoid breaking current apps by updating only Safari's WebKit. Meanwhile, everything that uses UIWebView should work just as well as it did before; if it doesn't (as with that caching issue?), then that part *is* a bug, and will be dealt with accordingly.
WebApps probably *could* have been switched over to Nitro, but it's probably the case that iOS runs them inside a basic UIWebView wrapper, which, naturally, uses the older WebKit, and it just wasn't worth making a special case for this little-used feature when system-wide changes to UIWebView are only a few months away.
Yes, Apple undoubtedly *will* upgrade the WebKit used by UIWebView with these improvements, but they'll save it for a major version change (eg iOS 5) -- a time when things are expected to break a bit anyway, giving both Apple more time to test the robustness of Nitro under a wider range of conditions, and giving app developers more time to find and fix any problems this might cause. There will probably be WWDC sessions on this exact topic.
Or, you know, they realized
- the number of people who actually own multiple batteries for their laptop or replace the battery outside of the warranty is actually miniscule
- the mechanisms and packaging needed to enclose a removable battery take up a significant porportion of the volume in the chassis, and eliminating that (by using a non-removable battery) would free that space for a larger array of battery cells, significantly boosting battery runtime ... mitigating the need to buy an extra battery among most of the few who actually do that
- by connecting the battery cells to the power controller directly, instead of through some 4-pin connector, they could significantly improve the lifespan of the battery cells through smarter charging ... creating a laptop who's battery life expectancy is finally on par with the typical useful lifespan of the rest of the machine
but oooh I like your version better: Apple TOTALLY decided to move to a more user-hostile design because that would somehow BOOST laptop sales five years later and increase their revenue from service calls.
(Even though most battery replacement is done while under warranty, which means replaceable or not it still needs to be checked out by a service technician who's being paid by Apple, not the customer, and replacing the newer internal batteries requires significantly more labour, so each battery replacement under warrant actually costs Apple significantly *more* than it would have before.)
I think it's more likely that they pushed web apps until they could get their store up and running. Whilst in the future, more and more of the software and services that we use will move in to the cloud, right now, not allowing third party applications would be a pretty big oversight. iOS is what it is because of software, it's a blank canvas.
In any NORMAL universe... saving a "web app" to the home screen would be nothing more complicated than saving an URL. Then when the user selected that icon, it would simply launch Safari.
For some reason known only to them, and maybe not even them, Apple has made it more complicated. Instead of launching Safari, it launches some other program which uses a UIWebView and therefore a different underlying web engine.
And that begs another few questions... why aren't they updating the web engine that UIWebView uses? And why doesn't Safari use that in the first place? Why is there such a redundancy?
Some have suggested that Apple didn't update the iOS web engine because it might break some small fraction of the various apps that depend on it. But when has Apple ever really worried that much about breaking something with an OS update? If something using UIWebView breaks, the developer fixes it... not really that big a deal. If the app is no longer supported, well it was bound to break sooner or later anyway.
Anyway, the bottom line is that Apple overcomplicated things and now it's bitten them on the ass. Now they simply need to decide how much they are willing to tolerate teeth marks back there.... either they'll fix it, or they won't.
For some reason known only to them, and maybe not even them, Apple has made it more complicated. Instead of launching Safari, it launches some other program which uses a UIWebView and therefore a different underlying web engine.
And that begs another few questions... why aren't they updating the web engine that UIWebView uses? And why doesn't Safari use that in the first place? Why is there such a redundancy?
Some have suggested that Apple didn't update the iOS web engine because it might break some small fraction of the various apps that depend on it. But when has Apple ever really worried that much about breaking something with an OS update? If something using UIWebView breaks, the developer fixes it... not really that big a deal. If the app is no longer supported, well it was bound to break sooner or later anyway.
Anyway, the bottom line is that Apple overcomplicated things and now it's bitten them on the ass. Now they simply need to decide how much they are willing to tolerate teeth marks back there.... either they'll fix it, or they won't.
It has been said many times in this thread but I feel that it has to be said again. If you and the person who wrote this macrumors article, had read the original source article properly, you would understand that this is not the case.
In 99% of cases, saving a web page to your homescreen will simply create a bookmark that will open that URL in safari. It does not launch a special application that has been purposefully made inferior.
However if the web developer was to add a specific line in the head of their web page, which has been mentioned already, it would allow the app to enter 'full-screen mode'. That is to say it will open the site in a UIWebView as opposed to in safari. This means that there will be no navigation bars, no address bar, no bookmarks. It will simply be a website and the bar at the top which displays the time and wifi etc.
Now apple has not deliberately downgraded anything. I am unaware if they have caused a problem with caching using manifest files but nothing has been deliberately taken out. All that has happened is that safari, which presumably is built off of a UIWebView, has been updated to support a new JavaScript engine whereas the standard UIWebView has not.
There are many applications that use UIWebViews, and not specifically full-screen web apps. Some of these include other web browsers. If apple were to update the whole UIWebView to use the new JavaScript engine, all applications would benefit from it, including other safari/webkit-based browsers. Now whether apple wants to have the best browser or whether it is just not something they updated is another matter. It could simply be a compatibility thing, who knows.
However as it stands, nobody is losing out by upgrading to iOS 4.3.
This has been publicly disclosed so will have to be rectified despite it being, in reality, an expression of the walled garden.article said:
There are other garden Easter eggs, but are nonetheless invisible.
Rocketman
I only use on WebApp, GPX+, but I would have thought it'd run as fast when you open in there instead of in the browser.
Not everyone's site has money to develop on the App Store.
It's $99/year. If you can't expense this then you aren't making a living off of your development efforts.
No, the Cloud is not the future. It's just another iteration of a solution in search of a problem. Instead of it doing a few services well, the proponents realized there wouldn't be any hype and thus venture capital if it wasn't projected to become the future of desktop computing.
The Cloud will get scaled back dramatically and do what it should have done early on and do it seamlessly, but as an extension of the Desktop/Mobile/Portable world of computing.
If you are building bespoke temporary apps to go on to three-to-five day events, not to be shown anywhere else and not to be sold, it's too much of a hassle to build a native app.
See my post below:
If you are building bespoke temporary apps to go on to three-to-five day events, not to be shown anywhere else and not to be sold, it's too much of a hassle to build a native app for each and every one.
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5)
Another issue nobody is apparently talking about is the one dealing with internal networks... If your business has servers set up as, http://mywebserver then you need to now type it in with the full search domain so 4.3 will see it otherwise you get the error cannot find page error. To make it work you have to navigate to http://mywebserver.mycompanydoman.local/webpages.html
Another issue nobody is apparently talking about is the one dealing with internal networks... If your business has servers set up as, http://mywebserver then you need to now type it in with the full search domain so 4.3 will see it otherwise you get the error cannot find page error. To make it work you have to navigate to http://mywebserver.mycompanydoman.local/webpages.html
This is Apple I would not put it pass them to have know of the issue and figure it was in their own advantage.
After all even if they are opening from the desktop it is still safari that is opening. Its not like the faithful will not cognitive dissonance them self out of a rational explanation.
This is Apple I would not put it pass them to have know of the issue and figure it was in their own advantage.
After all even if they are opening from the desktop it is still safari that is opening. Its not like the faithful will not cognitive dissonance them self out of a rational explanation.
As has been said several times, if you are opening a web app from the home screen, you are not opening up Safari. You are opening up a UIWebView with the page. UIWebViews were not upgraded as Safari was in 4.3, most likely due to Apple not wanting to break any apps that used UIWebView to render web pages (It's not just Web Apps that use it, many native apps do too).
Wirelessly posted (Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5)
The fact that rendering alone turns into a single slow thread and no caching support speaks for itself. No, that is NOT like iOS 4.2 and YES, 30% + developer fees to appear in appstore vs free is a loud and clear indicator of manipulation.
The fact that rendering alone turns into a single slow thread and no caching support speaks for itself. No, that is NOT like iOS 4.2 and YES, 30% + developer fees to appear in appstore vs free is a loud and clear indicator of manipulation.
It was a joke, hence the
smiley. I see more and more stuff becoming http:// renditions every year.That is exactly the issue - there's no developer lock-in or barrier to porting to another platform. If web apps are too well supported, then the (hardware) platform becomes irrelevant.
Huh? It still works for me just fine. Is your DHCP server handing out the correct Search Domain? (Check under Settings, General, Network, Wifi, details for your Wifi network; the current value is listed there)