Why Apple won't let you run in the background on the iPhone
by Volker Weber
Unless you’ve been stranded on a remote Pacific isle, you’re no doubt aware of the current furor over third party iPhone applications not being able to run in the background. To be blunt, I’ve never seen so many experts without a fricken’ clue. If you haven’t written code using the jailbreak tool chain, your opinions on the iPhone SDK, based entirely on what you see in a simulator, just aren’t relevant. You might as well be explaining the nuances of brain surgery.
As someone who has been involved in iPhone development for the past six months, please let me offer you a healthy dose of reality.
Comments
OK, the radios (both EDGE and WiFi) may have significant power requirements. But IMHO it is a bad solution to almost disable them. :-)
The Nokia 770 / N800 / N810 devices do not have such restrictions for developers. Even some default apps are designed to run as background apps, reconnecting WiFi and checking for updates every few instants. Those devices last more than 2 days on battery.
Then again, the Nokia devices only have Wifi and Bluetooth, but no cellular radio, so that's one hungry component less compared to an iPhone.
It will be interesting to see how ActiveSync bears on the iPhone battery. The Treo 750 is very quickly asking for a recharge, where the E90 is still going strong.
I have to say that something about this doesn't seem quite right since, just as others have mentioned, products from the Nokia & Blackberry stables do seem to manage the illusion of near permanent connection - to support push email for example?
Sure, if it's Wifi based then there's a bigger hit, but just keeping a cellular connection open shouldn't kill the battery. After all, that's what it's designed to do!
In any case, just as I reflect on this comment before posting, the issue is running apps in the background, not running apps that drain the batteries through 'over use' of the radios, isn't it? Not to run any apps in the background sounds like a return to Mac OS 9 to me, where that limitation was imposed rather than essential. I would suggest that in the case of the iPhone, this limitation has been imposed by policy or design not as some sort of 'physiological' limitation of the platform. My E90 runs many apps in the background. Some run the radio/wifi, others don't and the impact on the battery life varies accordingly, but the point is that it will run apps in the background.
I think I should join the throngs of uninformed non-SDK developer types who scratch their head and murmur 'Doh' at the lack of a background app capability. Where do I buy a ticket to the Pacific Island - or is it too crowded now?
John, the iPhone is also running plenty of apps in the background. Apple has chosen to not let SDK developers do that. As Craig Hockenberry writes, that may be a good decision fow now.
OTOH, it pretty much rules out that IBM could do anything interesting in the near future on the iPhone, if they cannot convince Apple to do it for them.
Right, John, somebody needs to tell RIM and Nokia that what they're doing in the "constantly connected" department just isn't feasible/possible.
Dang, and here I was thinking that my E61 could actually keep a connection open all day long for 2 days.
I could imagine that it's just an undocumented feature that you need to place a
struct timespec timeOut,remains;
timeOut.tv_sec = 0;
timeOut.tv_nsec = 100000000; /* 10 milliseconds */
nanosleep(&timeOut, &remains); instruction into your main loop to let background apps process normally.
Now, really. Where's the problem for Apple to design, say, a queue where requests for "connectivity" line up? It should be fairly easy for them to provide such a thing and by doing so limit the "pounding on the battery". Ok, you'd also have to implement another queue for the responses received from the network and make sure to deliver the right response to the right recipient but even that should be fairly easy to do.
Stefan, you can't start from scratch if it it turns out to be not as easy. You make commitments with an SDK.
