<

p>

iPhone_multitasking.jpg

Here we go with another hand of high-stakes SDK multitasking three-blogger stud. Commenters (as always) wild.

Craig Hockenberry, developer of Twitterrific for Icon Factory, opens with two reasons why he understands the current Apple-enforced no multitasking policy, power:

The heart of the problem are the radios. Both the EDGE and Wi-Fi transceivers have significant power requirements. Whenever that hardware is on, your battery life is going to suck. My 5 minute refresh kept the hardware on and used up a lot of precious power.

And presentation:

You now have five independent sources for notifications. How do you let the user know which one is which? One might say, “make the sound different.” Another might say, “make something flash in the status bar.” Someone else might say, “make the phone vibrate.” Or even, “put up an alert box.” A truly sick individual might say, “Do all four.”

Jens Alfke, who developed iChat for Apple before going indie due to creative differences over the importance of social software, sees power:

[... H]ow much less power does it take to leave the EDGE radio passively listening for packets, as opposed to sending them? [... M]y prior cellphone, the T-Mobile Sidekick, had excellent AIM support, as well as push email, from day one, so it clearly is possible. The Sidekick’s battery life was decent, with maybe 3/4 the standby time of my iPhone.

And raises on presence:

I don’t buy this at all. In fact, I think it’s paternalistic. Yes, user interface design has to consider unintended consequences of users’ own actions, but this is a situation where the consequences are entirely obvious to the user: the more notifications you turn on, the more distractions you’ll get. The remedy is just as obvious: if you end up with too many distractions, you turn some of them down or off by using the exact same steps you used to turn them on in the first place.

(Be sure to hit up the original posts linked to above and read the comments for several bonus rounds of back-and-forth between the two and with others.)

John Gruber of Daring Fireball brings the hand to an end, calling:

I believe the number one reason why the iPhone OS doesn’t allow background processes is RAM. Battery life, CPU sharing, bandwidth — all of these are factors, too, but I think RAM is foremost. The iPhone only has just 128 MB of RAM and no swap space. A good chunk of that 128 MB goes to the OS itself and the built-in apps that do run in the background — Phone, Safari, and iPod. There really just isn’t much left over. If Apple were to just allow background processing now, what would happen is that background processes would often wind up getting killed by the OS at some point when the frontmost app needs more memory. From the user’s perspective, it would seem as though background apps inevitably mysteriously fail and stop running. You can argue that you’d rather have that than no third-party background apps at all, but it’s clearly a reasonable trade-off for Apple in terms of consistency and obviousness in the user experience.

Is Hockenberry right? Alfke? Personally I'm not betting against Gruber on this one. The iPhone is the first smart phone (can we call it that yet?) I've ever owned that didn't crash almost daily when making or receiving calls, and being a smart PHONE, that's the functionality I -- and it appears Apple -- is most concerned with. As things progress, Apple can always add functionality. It's far more difficult (and nightmarish from a PR standpoint -- right AirDrive Time Machine?) to take it away when it falls apart later.

Come June, when Apple lays all their cards on the table, we might just have a better idea. Until then, what do you think?