A Reality Check On iPhone Restrictions

Many bloggers, developers, and people who should otherwise know better have been complaining about the "restrictive" native of the iPhone SDK and Apple's seemingly "arbitrary" limitations on iPhone applications.

Therefore it was with great interest that I read an article by Craig Hockenberry of Twitterific fame, which dramatically illustrates just what happens when Apple's guidelines are bypassed.

One such restriction related to the ability of third party applications to run in the background. According to the SDK, when a user leaves an application it's supposed to close and save its state, restoring things when the user returns. This usually happens so quickly that you hardly notice its occurred.

This swapping minimizes the impact of applications running under the iPhones meager 128MB of RAM, memory that needs to be shared by all of the programs and services on the phone. Just to put things into perspective, my 24" iMac has 4GB (4,000MB) of RAM. Heck, its video card, at 256MB, has twice as much memory as an iPhone.

And while we're discussing such things, the iPhone, with its integrated graphics and other systems, also needs a significant chunk of the 128MB just to run its hardware. In short, this leaves just over 70 megabytes for "user" applications.

Needless to say, there's not much room available for applications to leave things lying around, just in case the user comes back later.

But there are other reasons for an application to stay running. One is when an application wants to "poll" a device or service, periodically checking to see if anythings changed. Think of an application that, like the iPhone's SMS program, logs into your Twitter account to see if your friends have posted anything new and, if so, notifies you of the fact.

Unfortunately, almost any application of interest that wants to maintain state also needs access to the network, and that's where the conflict lies.

The iPhone is a battery-powered device that doles out power in sips and drips and drabs, managing resources in a truly parsimonious fashion. But the EDGE and WiFi radios are greedy bastards, grabbing all the power they can get, and then some.

Which brings us back around to Craig's article, in which he details how he developed an application, Twitterific, that in fact ran in the background and polled a user's Twitter account every five minutes. Not too often, and with what would seem to be reasonable restraint.

But this simple network check managed to completely drain the iPhone's battery in just four hours. As Craig says, "The heart of the problem is the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements, and whenever that hardware is on, your battery life is going to suck."

And that's just one, single application. Imagine the consequences of two, or three, or four of them?

Too many pundits have assigned nefarious motives to Apple, blaming the SDK's restrictions on "control" for control's sake, or on Apple attempting to "protect" its revenue streams.

But few, it would appear, also realize that an iPhone is not a full-fledged desktop computer, and that there are sound engineering reasons for nearly all of the decisions Apple has made.

It's also important to remember that the iPhone isn't even a year old, and that future devices may relax or even remove many of these restrictions. Then again, with users demanding 3G and GPS and other energy-hogging technologies...

They may not.

Deal with it.

Comments

[gerrit]

People also seem to keep forgetting that with EDGE you can't receive phone calls while a network connection is active. That means the more frequently you have background apps polling a network service, the more time out of the day you are unable to receive phone calls. If one or more apps use the network connection for a combined 15 seconds every 5 minutes, that's 1 hour and 12 minutes out of a given day that your phone will not be able to receive phone calls.

And because EDGE connections are slow to setup and tear down, what takes a fraction of a second on a desktop can take 10 or more seconds over EDGE.

This doesn't affect SMS, because SMS is a separate service from EDGE networking that is integrated with the phone services. (ie. Your phone can ring even when receiving a barrage of txts.)