Multitasking in iPhone OS 4 - my predictions

So, tomorrow's the big day; Apple will be having their event, and probably announcing the much-talked about tablet thingy!

I must confess to not being terribly interested in the tablet; I just can't see a realistic use-case for it. Now, maybe I'm being unfair, and Steve will come out with some obvious-but-brilliant application, and we will all suddenly need the thing, but for now put me down as sceptical.

What I am hoping is that we get a preview of iPhone 4 and, perhaps more importantly, its OS. The phone itself I don't think will be anything dramatic or unexpected; it'll be faster, possibly have more memory, possibly have a higher-res screen, maybe a flash (but not Adobe Flash, unless I'm very much mistaken)... The OS, on the other hand, could be interesting.

If there's one complaint about the iPhone that you hear over and over again, it's the multitasking issue. Apple have, of course, dealt with that to an extent through push messaging, but that only goes so far, as I'll show in a moment.

First, though, notifications, both of the push variety and things like missed calls, text-messages etc. The current system, where you have a single popup box showing the most recent thing is woefully inadequate, and I'm quite sure that something will be done about this, though I wouldn't care to speculate on what. Lists, categorisation, who knows? On a similar subject, it really should be possible to specify times when you do not wish to receive notifications. This is a no-brainer, and I'm pretty sure they'll do it.

The main point. Multitasking. Now, first, it's important to realise that the iPhone can multitask; at any given time any iPhone will be running multiple processes, and a number of Apple's own apps, notably Safari, actually stay alive in the background when you're running something else. It's simply that third-party apps do not have the option of doing this, and must shut down when closed. This is for good and sensible reasons; if apps were allowed keep going in the background, they would be using CPU, and thus power; they would also be taking up memory, causing problems for other apps.

Most smartphone operating systems effectively handle this by ignoring it; you are allowed multiple normal apps running, and they will effect battery life, and sooner or later, you will get a nasty message from the operating system telling you that you are using all your memory and must close apps, or else the apps will just be closed in the background. For a user who knows what's happening, this isn't too bad, but for the average person, it means that their phone runs down its battery quickly and gives them scary messages. So, in fact, even Apple's current approach to these things may be better than the competition, for most users.

So, you probably don't actually want multitasking in quite the way it works on Windows Mobile or Android, even though it looks nice at first glance. What sort of things do you want multitasking for?

1. Switching rapidly between applications. For instance, copying pieces of text from Facebook into Twitter, or popping out of your game to check the time.
2. Things like IM, where you want to be online constantly and receive notifications when someone sends you a message; you then want to load the app with the message open.
3. Periodic tasks; you want to check an RSS feed every 20 minutes, or something.
4. An extension of 3, really; location. You want to check your location, and notify a webservice of it, or keep a log of where you've been today, or whatever.
5. Hold open a connection to a stateful service like ssh or irc or whatever which is not designed for the iPhone, and is only really properly usable if the client holds their connection open for the duration of the session. Also, communication with services which for security reasons cannot go through the Apple push notification system.
6. Streaming media such as Internet radio, while using a second app.

1, looked at naively, seems to already be there; you can, of course, do this, assuming that the apps you are using take a sensible approach to being told to shut down, and save your current state and position. Most better apps do this. There's a catch, though. When you click out and into another app, you have to wait for it to start up and recover its position. Go back, and you have to wait again. If one of the apps is, say, a game, you might be waiting for some time. My solution; allow apps to stay running in the background for a defined time, maybe a minute, or until memory pressure becomes a problem, then shut them down. That way, you can switch quickly between apps. The OS should only do this for apps on request (from the app), and the app should be told about it so that it can stop doing needless stuff like drawing to the screen while backgrounded.

2 is already basically covered by push notification, though it would do no harm to make push notification a bit easier to use for the developer. Right now, you have to hold open a TCP connection to Apple; if the option were provided to push messages with a webservice, it would become easier to implement, and more practical on platforms like PHP where you don't have constantly-running processes, or Google App Engine where you don't have reliably running processes and you can't do raw TCP anyway. Number 1 would also help with some of the common push notification use-cases; carrying on an IM conversation while reading a webpage would be much nicer if you didn't have to wait for the IM app to start up every time a push message brought you back to it.

3 seems to me to have a simple solution; an application, besides the main GUI process, provides a separate executable to be run by the OS at defined intervals (setup by the main application). This lightweight process only loads what is needed to do its check; it performs its check, then quits, using far less CPU (and thus battery) and memory than the full application running constantly would. The process can create notifications as necessary.

4 could be done as an extension of 3. However, getting an accurate location can take a little while and consumes a bit of power. Perhaps the phone should do it periodically, and start up the lightweight process for each app which has registered to receive such data, giving it the current location. Minor optimisation; only do this when the phone's vibration sensor tells it it has been moving recently; no need to do it if it's been on your desk for the last two hours.

5 is on the face of it the hardest. My proposed solution would be to have a very simple, lightweight process which would stay active continually and do the necessary communication with the service. It would be very strictly monitored by the OS for memory and processor usage, and killed if it got out of line. The actual application, that the user interacts with, communicates with the lightweight comms application through IPC when running. The comms application creates notifications as necessary. As a variant, instead of providing a full comms process, the developer could write the comms section of their app in something like Javascript (easy to sandbox, and talking to a low traffic data service is not speed-critical); all such modules would then be run directly within one OS process. This could potentially cut memory usage.

6 is probably the most actually problematic. Another lightweight process would help, as you at least lose the UI overhead, but it's not as good a solution as the others. Still better than normal multitasking, though.

An interface would be provided for switching through applications, similar to the Palm Pre cards one. However, the images you'd see on 'idled' applications (in conditions 2-6 above, with the actual GUI application at least terminated) would be screenshots taken on termination; the applications would only be restarted if you selected them from the switcher interface.

I'm optimistic that Apple will take some measures along these lines. Just allowing arbitrary numbers of big hefty GUI applications to run, as the competition do, is all well and good, but in practice it would worsen the experience for a lot of users, pushing battery life down, and so forth. I suspect that the approach I've outlined would work better, with some more work for the developer, but improved battery life and reliability and little or no difference in functionality to 'proper' multitasking.