mikeash.com: just this guy, you know?

Posted at 2008-03-15 01:02 | RSS feed (Full text feed) | Blog Index
Next article: Use strnstr
Previous article: Code Signing and You
Tags: iphone rant
Deconstructing the iPhone SDK: No Multitasking
by Mike Ash  

The recent release of the iPhone SDK has created a great deal of controversy in the Mac community. In typical fashion, two sides have formed, with each side thinking the other side is a bunch of fools. I'd like to explore one big point of controversy: Apple's prohibition against running applications in the background.

To those of you who are late to the party, the iPhone SDK has many limitations on what your apps can do. Among these limitations is a requirements that applications not run in the background. In other words, when the user switches away from an application, it must quit.

Sadly, Apple does not explain their restrictions. A lot of rationalizations have appeared, but overall I believe that they make little sense.

Insufficient Hardware

The most common rationalization is that the iPhone is not powerful enough to support full multitasking. This is a curious argument, and it's hard to see how anyone who's been using a computer for more than a few years could make it. For example, here are the specifications of the first computer I used that could multitask, a Macintosh LC:

(Later I loaded a hack on my Apple IIGS, worse in many ways, which also let it multitask. But this was very much a hack, unstable and slow, so it doesn't really count.)

But, you say, this was poorly done cooperative multitasking. The iPhone runs UNIX! Well, here are the specifications of the first computer I ran a UNIX-alike on, a PowerCenter Pro 180:

And of course you can run UNIX on vastly less.

Now, compare these specs with the iPhone:

(Here is the original source for the CPU and the source for the RAM.)

CPU

It should be pretty clear that the CPU can handle running more than one program at once. You can't just compare the clock speeds, because the ARM architecture is vastly different, but a 620MHz ARM is plenty speedy. It's going to compare very favorably to the PowerCenter Pro and it's going to utterly crush the LC.

CPU speed isn't even very critical for multitasking. I've done realtime high-performance preemptive multithreading on an embedded CPU running at a couple of MHz powered by 6 AA batteries all literally sitting inside an oversized Lego brick.

Multitasking only increases CPU requirements by the amount of extra activity present. You can have a hundred apps all running on the slowest possible CPU if only one of them is actually doing something. On the other hand, you can run two applications on a really powerful CPU and they will fail if they both need the whole thing to run at the required speed.

Most iPhone apps will play nicely. Most people want to run in the background to watch for incoming messages or alert about events, hardly demanding tasks. Those which don't play nicely will not be very popular.

RAM

This is an even bigger one, according to most of the people I've seen. The device has only 128MB of RAM. Of course 128MB of RAM is luxury compared to many systems running full GUIs. To put this in perspective, 128MB of RAM was the minimum system requirement for Mac OS X 10.3, and it handled multitasking just fine.

Of course the limited RAM is greatly compounded by...

No Swap

The iPhone has no swap! Panther could get away with 128MB of RAM but it would swap like crazy. Without swap, the naysayers claim, there's no reasonable way to allow arbitrary multitasking.

This is true but misses the point entirely. The question is not whether the iPhone can support multitasking without swap. The proper question is this: why doesn't it have swap?

The device is clearly technically capable, so why doesn't it do it? I speculate that it may simply be a holdover from when the iPhone only ran Apple software and therefore didn't need it.

Battery

At last, one which makes some sense. Runaway background apps will kill your battery, making for an unpleasant phone experience.

However, if you don't want runaway background apps killing your battery, don't run them. This is particularly true if Apple is going to play nanny to us all and only let us use approved software. Part of the approval process could be making sure they behave nicely in the background, rather than the current state of making sure they don't run in the background at all.

Better yet, the OS could be made a bit smarter and heavily deprioritize background applications, such that they would not be allowed to use a large proportion of the CPU even if nothing else wants it. This would ensure that battery usage is kept to a minimum while still allowing apps to keep a watchful eye over whatever they need to monitor.

Conclusion

The situation with the iPhone SDK is frustrating for many reasons, not the least of which is the fact that Apple refuses to explain any of its actions. This leaves the rest of us guessing. A lot of people have guessed that this particular limit is due to technological restrictions, believing that the iPhone is simply too limited to handle true multitasking. I hope I have made a convincing case that this is not true. Apple's motivations may be based on user experience or limited engineering time, but the hardware itself is more than capable.

Did you enjoy this article? I'm selling whole books full of them! Volumes II and III are now out! They're available as ePub, PDF, print, and on iBooks and Kindle. Click here for more information.

Comments:

My suspicion is that the people lobbying on for performance (and probably AT&T worries about network usage) have won temporarily and this feature will arrive when the OS becomes smart enough to do things like not only throttle CPU/memory/network activity but also do things like requiring activity to be in response to events (incoming packets, timer, etc.).
Well, if you count timers as events then any OS already restricts activity to be in response to events. I can see where they might want to make things more restrictive than usual, but it seems like they ought to have done that already instead of forcing everyone to be foreground-only if that's the case.
You say: "However, if you don't want runaway background apps killing your battery, don't run them."

How do you tell if an app is a "runaway?"

This is the fundamental problem of Computer Science: the Halting Problem.

Not so easy to solve.
I wish people wouldn't bring up theoretical objections where they clearly don't apply. The halting problem only applies to automated determination of certain properties of a program with 100% accuracy. It does not mean that a human can't determine things to his satisfaction, and it does not mean that a computer can't place more restrictive limits, like, say, killing any background app that sucks up 100% CPU for more than five minutes straight.

If you're battery-conscious, don't allow background apps. (It would presumably be an option.) If you really want them, then monitor their resource usage and kill them if they misbehave. Not rocket science and hardly deserving of the "halting problem" treatment.

Comments RSS feed for this page

Add your thoughts, post a comment:

Spam and off-topic posts will be deleted without notice. Culprits may be publicly humiliated at my sole discretion.

Name:
The Answer to the Ultimate Question of Life, the Universe, and Everything?
Comment:
Formatting: <i> <b> <blockquote> <code>.
NOTE: Due to an increase in spam, URLs are forbidden! Please provide search terms or fragment your URLs so they don't look like URLs.
Hosted at DigitalOcean.