Apple handcuffs 'open' web apps on iPhone home screen Apple's iOS mobile operating system runs web applications at significantly slower speeds when they're launched from the iPhone or iPad home screen in "full-screen mode" as opposed to in the Apple Safari browser, and at the same time, the operating system hampers the performance of these apps in other ways, according to tests …
..when Apple refuse to release a fix. Right now the story basically boils down to "there are some possible post-release bugs with iOS 4.3. Bug reports have been filed, but no feedback has been given yet".
Apple have earned the reputation that makes everyone suspicious of them, but it's a little early to call them evil on this specific issue.
It really could be a bug - especially if it is found that Nitro is part of Safari and hard to use outside, but stopping web apps from running without a connection is a new and deliberate step, IMHO
There is a world of difference between profits from good ideas and profits from restrictive practices, and Apple will get absolutely no sympathy from the courts with their dominant market position and hugely increased profits from iOS devices.
Watch this space...
"..when Apple refuse to release a fix."
I agree in the main with this, although there is some indication that they are already not considering a fix as yet (allegedly) - from the article
"if Apple didn't specifically introduce these problems in iOS, it's aware of them now. And he says that the Mobile Safari team has indicated the issues will not be fixed."
As a developer, i'd have thought it was marginally more work (more code paths) to get two different rendering engines being used depending on their source - and it's certainly in keeping with their apparent bias towards self, rather than consumer, interest to do this deliberately - but it *might* just be a screw-up. Personally, and as an Apple user, i'd bet against it alas.
If it was deliberate then presumably they either
(a) thought that nobody would notice, which smacks of gross stupidity, or
(b) thought that people would notice but think of themselves in a position that they don't have to give a shit; not that they'd do that of course.....
Apple is doing everything it can to maintain its monopoly in iTunes. Or, so it thinks.
Forcing competing subscriptions to pay a high 30% cut to Apple making them 42% higher in cost to the consumer is just one method. Hoping they go away to avoid the cut is another.
It is very clear that Apple wants to deceive customers into thinking that doing everything just the way Apple wants to paying Apple a fat 30% cut is the best way.
Apple is deliberately screwing its own customers.
You thought Microsoft was bad.
Do not buy Apple products. You will regret it.
Are you some sort of robot, posting your identikit comment to every Apple story that appears?
There are no grounds whatsoever from which you can conclude that Apple's 30% charge on subscriptions is an attempt to deceive customers. You've taken one wrong and used it to allege a completely unrelated offence.
The problem with believing in conspiracy is that there are no profits to protect!
The idea is that a free web app bites into apple's 30% margins, but the same thing as a free App, Apple gets 30% of nothing, which last time I looked is nothing.
I'm betting that this is a case of needing to extract the code to run standalone, and we will see performance improve with 4.3.1.
You're looking at this with blinders on, it's not about one of two free applications. Apple's mobile strategy is based on positioning itself between content/application providers and it's device owners so that it can control content access and extract a profit. To protect this Apple needs to continually guard against efforts by application developers and content providers that might chip away at that control and the profit stream it represents. I wouldn't be at all surprised if, at the very least, this is deliberate foot dragging on the part of Apple. Addressing the issue is simply not in their best interest.
One good reason Apple could, quite wisely, wish to wait before upgrading the full screen web-browser UI to the Nitro engine, is it uses UI Web View which is shared by native apps. Many native apps invoke webviews and rely on JavaScript functions. If the JavaScript implementation has changed even slightly, it is likely an upgrade will break some apps that have already passed the AppStore tests and been released. It is standard and professional practice not to force a change of API implementation on tested apps. Something Google would do well to learn with their Google Doc API, BTW. The analogy here is a perfect example of the problem. On multiple occassions now my app interface to GoogleDocs has stopped working because Google have changed the implementation under my feet - even though they have built into GoogleDocs a schema for defining and choosing an API version so any changes should be isolated to new versions of the API. The last time it was because they changed the way .docx files are parsed. Files that were one day converting fine stopped converting. If I had a released commercial app, they would have broken it and I would have customers clamouring.
But hey, never let reason stand in the way of a good conspiracy. Apple must be evil.
Apple needs to keep the gravy train going. That is why they despised Adobe and Java so much; they lose control. While Apple was promoting support for HTML5, I knew they would do something to hamper it, otherwise they lose the app store. Why would you need an app when you have access to the Internet and have access to countless on-line apps.
Yes, Apple initially said that web apps were preferred. But they also denied that they were developing any kind of tablet/slate device, for example. You simply can't take anything Apple say as indicative of their future behaviour.
It is entirely conceivable that Apple had always intended for native apps on iOS, but the integration/SDK/store just wasn't ready in time for the device launch.
Apple have never denied they were working on a tablet or slate. They never confirm or deny their plans in advance.
As a result of that, I agree that they very often have plans they haven't discussed and that we can't conclude with certainty that the SDK wasn't a plan at initial launch. But it's wrong to impute dishonesty.
Conversely, in response to the original poster, half a decade of maintaining a bridge between their native APIs and Java and citing Java as an on-the-box feature, then half a decade of maintaining it internally at their own cost, then a collaborative effort to transfer maintenance to the same people that maintain Java on Windows — including providing source code and documentation — suggests they probably don't despise Java.
Sun was more than willing to create Java for iOS and yet Apple would not let them. While Apple developed the Java port for OS X, Sun would have as well. Apple wanted to keep control of it and Sun was more than willing to let them. Given that they are killing it on OS X and never allowed it on iOS that really tells you something especially since they just launched the app store for OS X. Red between the lines and you will see that Apple likes control and money and no Java gives them greater control.
Ever think that Apple transferred it because they know they still need it, I know I use it and that is at home. So it is just not an enterprise that needs it.
I suspect web apps were only the "preferred" model because all the plumbing to the App store platform and SDK wasn't completely ready when the phone came out and it was far better to recommend that and say it's "the master plan" instead of, "oh yeah, please don't jailbreak and hack your phone...the tools and channel to sell it all aren't quite ready yet"
That isn't to say Apple hasn't been a leader in supporting HTML5 and open Web development -- just that the native platform takes precedence. I think that was always the end game - It's pretty logical.
How can this be anything but deliberate? Surely to have 2 javascript engines and choose between the based a url starting file:// or http:// is more work than not?
I can't imagine what sort of architectural mess must underly iOS that would amount to this genuinely being a bug.
BTW I hear that iOS clocks have gone wrong again on the change to daylight savings time in the US. Whatks going on there?
It can be something other than deliberate because the faster javascript engine is new to iOS 4.3. Being new code, no matter how well tested, there's a possibility it introduces obscure bugs in edge cases. They've therefore likely followed their standard iOS procedure and kept a copy of the older version, to ensure that apps linked and tested against the older behaviours aren't inadvertently broken. So they'll have two javascript engines around for as long as they support iOS 4.2 as a deployment target for things on the app store. At present they support back to iOS 3.0.
It's also nothing to do with http versus file. If you read the article, you'll see that web apps no longer appear to be cached locally. So both routes are http. The distinction seems to be between UIWebViews, used everywhere except Safari, and Safari. Their browser is a lot faster than web content displayed everywhere else.
It's more than possible that they want to get a significant amount of field testing done for free by incorporating the new engine into Safari. When they're sure it works properly, they'll put it into the standard web component used throughout the OS.
So does that mean it will take Apple the better part of a year or two to fix it then? They still haven't sorted out the clock and they have tried to fix that how many times?
iMovie had a two year old audio bug.
How about critical Java flaws and five months after other Java releases were fixed Apple still didn't have a patch.
It has taken Apple months to fix QuickTime bugs as well.
Hoe about RAID Admin, it took Apple a year to fix a bug.
They beat MS and their 17 year old bug though.
This is why I stay away from apple. Alot of their products are designed not for consumers convenience but rather apples. Make it looks nice and fashionable and the lemmings will forgive it and make excuses for it. Imagine if MS did this stuff. There would be an uproar and every news channel in the evening would have the story.
Time for some anti-trust shit to hit apple.
Antitrust is likely to hit Apple.
The effort to charge music subscriptions with a 30% cut forcing the cost to consumers to go up some 42.8% to cover is clearly anticompetitive. And Apple does have a strong or dominant position in the iTunes to protect. They have no problem doing so illegally.
Keep Apple customers away from competing alternatives or force a nice juicy 30% cut on all subscriptions.
Apple is out to screw Apple customers.
It does not take much intelligence to figure out a way to illegally control the marketplace. All it takes is the market position necessary to pull it off. And that is why such acts are illegal. Many have figured it out before. And many have decided it does not benefit consumers.
Apple does not give a crap.
I believe the US Department of Justice are already looking into the area. There's some suggestion from the usual quarters that connections between Google and the current administration may have helped expedite the issue, but absolutely no suggestion that the investigations will be influenced in any way.
The problem is that they wouldn't actually be leveraging their iTunes monopoly. To find competition infringements, authorities will need to establish that Apple have and are using a dominant position in one market to distort competition in another. In this case that'd be a dominant position in app vending to distort various subscription models. I actually think there's a good chance because Google aren't the only app vendor for Android so pure Android sales numbers aren't the question and iOS people tend to spend more on apps anyway. Apple's subscription rule limits what those offering subscriptions can do about passing Apple's 30% on to the consumer and thereby seems to distort the market.
That all being said, I maintain that Apple think they can use their current position — for as long as it lasts — to gauge subscription vendors, not that they're intending to keep down competitors.
Most likely outcome is the same as the Javascript, C, C++ or Objective-C clause; competition regulators will visibly sniff around, Apple will climb down before it gets to anything formal.
Apple throttle free web apps in preference to "real" (paid for) downloaded applications, 90% of which are little more than a wrapper round a public website which could be handled in HTML/CSS with media="handheld" or "@media handheld" by any half competent web designer?
Not to mention said webdesigner would then have a site suitable for iphone, Android and Micronokia all in one go...
Nah, I don't believe it.
So, Apple improve the speed in Safari and people complain because it's not improved everywhere?
If Apple don't fix this over site in the next FW release then please feel free to continue with your Apple bashing. But until then, I will give them the benefit of the doubt.
I'm sure many others won't - but haters gotta hate.
Pointing out illegal acts is not hate.
Neither is pointing out technical restrictions like commingling code and imposing technical disadvantages on alternative means. Blocking Flash is just one of them. Not fully utilizing HTML5 is yet another.
Do you really think that Apple engineers do not know any better? If so, that is hardly a reason to buy an Apple device.
Apple has no monopoly - curiously on players it's not far off, but customers have multiple ways to secure music, and if they want subscription content the only stipulation is that it must be available to customers via the app store at the same price as elsewhere (not as 42% more as you have twice claimed up thread).
Making shit up is what makes it hate.
With the advent of HTML5 it's becoming easier and easier to develop application that mimic almost or entirely the functionality of their native counterparts.
Take this for example http://bbc-news.snaver.net/ it is almost on par with the bbc's equivalent, yet can run straight from the browser. But then I guess Apple misses out on its big 30% cut? Ho hum indeeed.
Apple - run everything on our OS through us from us and no-one else, do not do anything we don't approve of. Leave us and lose everything!
Google - run everything through a browser on the web, no matter what, give us all your information along the way...we decided we own it anyway, even if you didn't specifically give it to us.
MS - run whatever is developed for our OS on our OS and use applications through whatever browser is available. Here are some protections and warnings but you can do what you want with your PC.
As much as I detest some of MS's past practices, I have to say I'm happiest with MS's approach. I only despair that WP7 might set a trend like Apple's. Here's hoping that Windows 8 won't lock us out from doing what we want.
I am not an apple fanboi, but this sounds like a Bug or something that they planned to leave out of the 4.3 release for development reasons eg, not enough time, or it threw too many bugs when implemented.
Its a little too soon to confirm Apple as a shepherd for devil (even though they are w8nker$ now and then)
Hmmm... Replying to my own post - how quaint.
Anyway, surely the easiest way to determine if it's deliberate or not is to check Apple's web app developer documentation for iOS 4.3 to see if caching and whatever else isn't working is still supported. I would do it myself but don't really know why to look for.
Yep, don't believe it, because you got it wrong: Real apps which are are launchers for a webapp are in the same position as web apps on the homepage - they run 2-3 times slower than run directly in the browser.
Nice how everyone is skimming over that. Its a conspiracy!... to make paid apps run slower than they need to…
I think Apple are so tied into symbolic dates and launches, occasionally this kind of stuff happens, and they didn't have time to fully integrate Nitro, they just managed to get it into the browser before His Stevieness had to get up on stage and launch ios 4.3.
...page loading is severely crippled when running a Safari shortcut from the home screen. The page is initially loaded full screen, rather than within the Safari wrapper, and freezes up until the page is fully loaded (or reloaded, which happens every time you launch it).
This is particularly frustrating for 'launch pages' which merely contain links to other useful mobile content - the links cannot be clicked on until the page is reloaded, which takes unnecessarily long.
Not to mention the propiatry 'iPhone web app' icons that the site needs to host so the launch icon shows correctly. Why can't they just use favicon like everyone else, which can include multiple resolution icons anyway?
Apple need to revamp their web app strategy, badly. I suspect a lot of it made more sense when web apps were their sole iPhone mobile app solution, but they occupy an entirely different purpose now.
Reading through your sources, Cade, I think you've got this story a bit arse over tit.
Create a quick icon from Safari on your iPhone home screen and all that icon does is launch Safari at that URL. There's no difference in speed to opening Safari and typing in the URL, or using a bookmark.
However, Apple has provided custom bits of HTML which you can use to hide Safari's controls, if you want to use the full iOS screen (they've also added tags which let you do cool stuff like specify a startup image, which makes your web app even more "native-like").
For some reason, if you use the tag to make your app go full screen, Safari's new Javascript engine (Nitro) fails to work. This is pretty clearly a bug: If Apple wanted to kill off native web apps, it would be deprecating the HTML extensions and/or simply removing the ability to go full screen. Note that Android, for example, doesn't have equivalent extensions at all.
As for the whole UIWebView issue, again, this is a bug (or, more likely a security issue). As you note, some developers simply create native apps using HTML/Javascript and UIWebView, to sell through the app store. Why would Apple degrade that experience compared to online web apps deliberately, given that these apps deliver them revenue, when online ones don't?
But this bit made me a tad more suspicious of intentional "sabotage":
"With earlier versions of the OS, if you move the game to the home screen and run it once, you can then play it offline. But if you try to do so on the latest version of the operating system, you can't."
Anyway, software is complex, could indeed be a bug or unintended consequence of some other, desired change (and poor Apple, they are so adorable, small and cute like that, can't even pay for extensive testing, just like the FOSS projects, aw...), who knows, blah blah. Time will tell, I guess.
Just tried the suggested Pie Man: installed it to the home screen, ran it online. Then switched to airplane mode (all comms off) and tried it again: launched from home screen properly, played a game. Don't know about speed comparisons, but the bit about not being able to run web apps offline due to the cache not working seems to be wrong, at least in this case.
i am updated to iOS 4.3... are you guys on the latest release?
i just tried it myself and i just got a slightly better score on the home screen launched test (4069ms) vs the safari test (4192)...
i've read elsewhere that this speed difference will only affect fullscreen web apps (of which the sunspider test isn't).. so for that test you should not see any difference at all..
I'm the technical lead for a fairly substantial iOS-targeted web app that has a major offline component. And I can state the offline app caching via the HTML5 manifest does work.
There are issues with caching that can lead to frustrations and outright failures (the implementation is very sensitive to errors in the manifest file format and the user/UI feedback and API for controlling cache leaves a lot to be desired). But we are running this app offline as needed.
Regarding performance: We have not yet benchmarked our app running under Web.app (the home screen Web app runner) vs. Safari.app on 4.3 yet. The app is do quite a bit work charting mid-sized data sets, so speed matters.
I'm an apple hater - I hate the closed approach and a lot of other business practices but in this case, it really does seem to boil down to
The browser launched from the home screen AND OTHER APPS doesn't have all the speed advantages of the native browser
Sounds very bug-like to me - either the actions kick of a slightly different browser UI or something similar - maybe it's a sandboxing issue.
If it doesn't get fixed, I'll be near the front of those booing Apple's dev team - but even I'm having trouble getting worked up over what seems like a simple bug.
web app performance is only slowed in full screen mode..i.e. if apps don't run in full screen mode i.e. they run in safari with nav bar etc at top there is absolutely no difference in performance at all
just go to the sunspider test directly i.e. not the link they provide in the story.. just go directly to the page and run the test and add a link to the home page.. no difference in speed at all.. both will utilize the Nitro Java Script engine..
could be a bug... could be Apple forcing web apps/pages to look more like webpage.. since if they don't run full screen they get all the speed benefits of the Nitro engine... they are in not locked out of it unless they run full screen..
what it really looks like is that the "Nitro" java script engine was only added to Safari in iOS 4.3.. as opposed to Webkit.. native apps use webkit to render webpages and when full screen mode is evoked that is likely rendered using webkit as well (not the same thing as running in safari)... there are many browsers on iOS that use webkit but don't look anything like safari.. have tabs, transcode Flash etc etc..
could be a bug, could be Apple forcing "Web Apps" to look more like webpages, could be Apple trying to differentiate Safari from the other browsers on iOS?? but devs are certainly not locked out of using the Nitro javascript engine at this point as long as they run there web app/webpage in safari..
Installed Pie Guy to my home screen. Ran it. It's a stupid game. Put phone into Airplane Mode - no Wifi and no 3G internets. Played Pie Guy again, without any pop-up dialog telling me it needed to be connected to the Internet. Still a stupid game. Maybe Neven Mrgan fixed his app since you ran this story.
Apple does a lot of stuff I disagee with. But in this case, I would assume the browser and desktop are handled by two different teams. Using version control, the browser guys have their branch, improved the javascript engine and checked it in; the desktop guys would have their branch where they'd do their thing, check it in only to find that the javascript engine in the browser is now out of sync. I don't see any conspiracy here.
Second bit of perspective, on my Droid 2 Global, which has a 1.2ghz TI OMAP and Android 2.2, the browser Sunspider benchmarked at 6549.9ms. It benched like 5300ms on my 1.3ghz Atom netbook which has Ubuntu 10.10 with Firefox 3.6.15 (Firefox has been getting good Javascript speedups of late too.) (Why don't I say "the benchmark ran in 5300ms?" Because it took a good minute or two to *run* -- it runs a bunch of times to ensure a +/- 5% accuracy.) Point being, a 10000ms time shouldn't be crippling.
Something interesting.. here's some Sunspider results I found from 2 sources, both using Core 2 Duo 3.0ghz one in Dec. 2007, and one in March 2011. Every bowser has HUGELY sped up in that length of time:
Firefox 2.0.11: 10,471 ms
Firefox 3.6.13: 753
Firefox 4.0 Beta 12: 247
IE 7.0.6000.16546: 21206.4
IE8: 3746
IE9 Final Release: 214
Safari 3.0.4beta (523.13): 6583.6
Safari 5.0.3: 310
Opera 9.50.9613 beta: 5391.2
Opera 11: 240
Finally (no 2007 results)
Chrome 10: 248
Chrome 11 Developer: 243
Reminds me of how Apple has become what they attacked first. (http://www.youtube.com/watch?v=R706isyDrqI)
I refuse to give this company even an ounce of my business because of how totalitarian they are. There is no reason for them to try and practice so much control over me and my device. Long live Linux.
If Apple wasn't this successful it would not garner so much dislike. I know of only one company that was both successful and generally liked in its day, and it's Palm (before they fouled it all up).
Which is not to say Apple is not Evil. It's looking out for Number One, and to hell with any scruples. If it's legal and profitable, Apple's doing it. And it gets most of it right too, its devices and software work in remarkable unity, the "user experience" is the standard everything else is compared to. It may not have invented much of the features it sells, but what it sells works pretty much as advertised out of the box, and not many non-geeks cares about the limitations. It's all shiny.
So what if Apple stunts free web apps (through negligence or by design), and gently tilts the playing field and nudges its sheep towards its app store? Will the millions of its customers care, or even notice? Certainly not.
Homework: compare the app uninstall procedure between Android and iOS. It's a simple thing. Count the number of taps, and the length of the "wait"s.
Disclosure: I am a geek, and currently use an Android device out of convenience. And as far as demographics go, I don't really matter. And neither do much of the people commenting here.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
