"And right about now, you’re thinking “But I’ll be smart about how I use the hardware.” Sorry, bucko, but you’re the exact reason why we don’t have background processing in the current SDK. You’re living in your own little dream world.
What happens when App A uses the network at 5 minutes past the hour, and App B uses it at 10 minutes past, and App C uses it at 15 minutes past, and so on? There’s no way for you to know what other apps are doing is there? And yet the battery is still taking a pounding."
Very convincing. Very, very few users would actually CHOOSE to have their phone to die (no calls in or out!) in no time flat. Or choose to have their music/movies die early. The risk would sometimes be just that great--and worsening as devices age--and it's not a risk users can make a fully INFORMED choice about if they don't know exactly what multiple apps are doing relative to each other. User choice is not a good option, and Apple WOULD be publicly crucified for giving users such a choice. Much worse, I expect, than they'll be attacked (tempest in a teacup) for not giving the choice--considering that people are already very satisfied with their iPhones before ANY 3rd-party apps have been officially offered.
The end of the article suggests a clever technical solution, coordinating multiple apps at a lower level, but rightly points out that expecting such a solution in the first beta SDK isn't realistic. The SDK and iPhone OS are greats tool already, but that doesn't mean new features won't be added to them in time.
I was thinking the same thing with a battery life warning when going to instal the apps. It would make sense, and you could no longer complain to apple or the developer. All problems solved.
I don't think a warning and a choice is the effective, simple fix some people are imagining.
People WOULD still complain, a lot. And then the press would exaggerate the complaints further. The reality of the situation would mean little.
And the fact is that saying "Yes" to the warning would be a poor choice for most people, when you start talking more than one app bought for the same phone. So it would need to be a very direct and clear warning, enough to STOP most people (who are not tech-heads like us) from going ahead. And it would need to be presented clearly every time you consider an app--not just hidden in the Terms of Service. Nor could Apple show the warning only once--on the first background app you buy, or on a single global setting that allows/denies all apps to run in the background. That would be a warning people would see once (and probably not give their full attention to) while exploring a million other things on their new device, and then they'd forget about it. And then when they go to buy an app, if that warning does not re-appear, tons of people later on will accidentally either do something that could kill their talk time, or else will pay money for an app that they can't fully use. One that can't really do what's expected unless the background option is enabled.
A clear, informative notice might be something like "
WARNING - this app may have harmful results for many users: installing this app, especially in conjunction with other apps, may greatly reduce your device's battery life, possibly to the point where it no longer functions acceptably for your needs. You purchase this app at your own risk, and Apple will not provide recourse or support if the device's battery performance becomes unacceptable."
Should such a warning be presented before or after purchase? Before would mean people browsing apps would get the frustrating impression that Apple was allowing lots of "bad apps" in their store that they get warned away from. After would be worse. And either way, Apple would have to spend time CHECKING every app (or doing programming modifying the SDK to automate this) to see if each app earned the warning or not. You can't give the warning for ALL apps or it will be ignored, a la Vista security. And you can't be on an honor system where developers voluntarily say whether their app should have a warning (one that would slash sales) or not.
Then, if the warning IS clear enough to be effective for non-techie users, you would have the backlash from developers objecting to the warnings. This too would be blown out of proportion by the press. (In fact, even a vague and nearly useless warning would cause some developers to raise a stink. No matter how few, the press would make it sound like a major uprising.) Then we have the press not only scaring off Apple customers, but worse: scaring off would-be developers!
And then there would be the battery-life bad press: "my 2-year-old iPhone dies in less than an hour of talking!"--situations resulting from apps that may have shown warnings "way back when," but later on, when battery life becomes unacceptable, will the aggrieved party remember the warnings and say "oh well, my bad" and remove the apps? Or will they rant loudly and get quoted by the Associated Press in articles that mention iPhone battery life but never mention 3rd-party background apps at all?
And when a user or developer who REALLY wants a certain background app tries it on a brand new iPhone with no other such apps, and gets acceptable talk times, of course that rosy best-case situation will be passed on to other would-be buyers of the app. But then one day the battery consequences will still happen, and some users will see a worst-case instead of a best-case.
It's just too complex a situation for Apple to solve simply, as much as I would love it to be otherwise. This is a very real, practical battery life concern. And I really don't see any way that mere warnings could prevent everyday users (not us tech-focused form-goers) from getting really mad--with resulting bad press on a large scale.
And don't forget the possibility that other iPhones and touch devices may be coming--and some may have less battery life to spare. 3G phones. Maybe smaller phones. Certainly, one day, smaller iPods. (Which would spend battery trying to find WiFi even if none is available--and for many people, WiFi IS available all day, both at work and at home.)
Now, I can certainly understand
some people wanting a device that doesn't hold their hand, and lets them trash the battery at will. But they already have a choice: choose a different platform. (Which might include jailbroken iPhones, for that matter.) But I think MOST people--who don't crawl tech forums, rant on developer blogs, and the like--the everyday people who make calls, surf the Web, listen to music, watch TV shows, and love that their iPhone/iPod "just works"--will actually benefit from Apple's no-background-apps policy. These are the people who will make the mobile OS X platform far bigger and more mainstream than any PDA, smartphone, or ultramobile platform has ever been. They'd love to get instant AIM notifications, but they love their talk time more, and are used to having
no AIM (or whatever) on the go--so AIM with limitations will still be welcomed. This huge group won't suffer much from having to touch the AIM button before AIM (or whatever) is functional.
A
technical solution at the OS level
may be doable--there would still be battery loss, but less so. That's not simple either, and will have to evolve with time. Remember how surprised developers seem to be with just how capable the SKD already is. Apple hasn't wasted their time, but they can't deliver everything immediately. Eventually we may have our cake and eat it too! I certainly hope people keep Apple aware of the demand for background apps.
