Next article: Use strnstr
Previous article: Code Signing and You
Tags: iphone rant
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.
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:
- CPU: 16MHz Motorola 68020
- RAM: 2MB
- Nonvolatile storage: 40MB
(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.)
- CPU: 180MHz PowerPC 604e
- RAM: I forgot, but probably 32MB
- Nonvolatile storage: 2GB
Now, compare these specs with the iPhone:
- CPU: 620MHz ARM
- RAM: 128MB
- Nonvolatile storage: At least 4GB, up to 16GB, usually 8GB
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.
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...
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?
- Speed: Swap would be too slow, some say. But swap is essentially random access, thus the single most important factor in swap speed is the seek time of the storage device. The iPhone uses flash memory, and flash has basically no seek time It's 100-1000 times faster than a hard drive. Swapping to flash will in most cases be much faster than swapping to rotating magnetic platters.
- Wear: Flash has limited write cycles! The typical flash drive can only be written to between 100,000 and a million times per cell before it wears out and stops working. People tend to interpret this as meaning that flash drives are delicate and need to be manhandled as little as possible to survive. But this is simply not true; the limit is per cell. Modern wear-leveling algorithms spread out the writes across the entire drive. A modern flash drive will last for decades before failing even when it's being written to at maximum speed all day every day. The flash drive will be the last component of your iPhone to die.
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.
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.
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.
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.
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.