« Interlude | Main | What *I'll* be using the iPad for »

Why the iPad may never need multi-tasking


Like the iPhone and iPod touch the iPad does not allow multi-tasking of third-party apps. That is, if you are using one app and want to start another you must close the first app. I wouldn't rule out that changing in a future update, but I'm more inclined to think we won't see it even on the iPad - at least not in a general form. Why?

The way I see it multi-tasking is used for three purposes:

  1. Background apps, such as music players. The iPod app does run in the background, of course, but there is certainly a case for third-party apps such as Spotify or to have the same ability.
  2. Notifications. This is at least partly addressed by the Push Notification service that Apple now provides. More on that in a moment.
  3. Fast switching between apps

I'd say that (3) is probably the number one reason we usually have so many apps open at once. After all we can usually only interact with one at a time. As the time it takes to (save and) quit one app and start (and restore) a new one gets closer to zero our need to have the apps open just so we can switch to them diminishes or disappears. From what I have read and heard the iPad gets us pretty close to the threshold where this happens. By some reports it crosses that threshold. I'll reserve final judgement until I see it with my own hands (mixed metaphor intended).

Going back to reason (2) let me explain what I mean by being only partly addressed so far. Imagine a calendar-type app - such as Event Horizon. You set up events and appointments - which may be days, weeks or months later. Ideally the app would be able to alert you of upcoming events in much the same way that Apple's own calendar app can already do. One way to achieve that now would be to use the push notification service. This would work but has two problems. First it's a bit heavyweight. Your event data would need to be synced up to a cloud service which could then decide when to push a notification back to the device. Cloud services certainly have their place, but bringing them in solely to provide alerts seems out of proportion. Secondly it means you will not receive the notification if you don't happen to be connected at that time. You will get it when you do get online, but that may be too late! Furthermore you need to be connected for the alert to sync up to the cloud in the first place. These all seems unjustifiable limitations when it concerns data that you already hold locally on your device. Therefore I think it reasonable that some sort of Scheduled Notification API should be made available. This could work just like the Push Notification service, allowing badges, messages and alert tones to be "pushed" to the user, with the ability for the user to open the associated app straight away, or defer that until later. The difference would be that the notification would be posted by the app itself for delivery at a specific time in the future and would never leave the device. I don't see any technical challenges to providing such an API.

If a scheduled notification API is made available I think the only significant remaining need for background tasks would be for things like music players. If Apple do allow background tasks in the future I think it will be limited to these types of tasks, and very strictly policed in the app store approval process. I'll say again, I don't believe Apple will ever allow general purpose multi-tasking in App Store apps. - and I don't believe they need to with the concessions just described. Note that I am ruling out other scenarios such as video encoders or bit-torrent clients, which I don't think are appropriate apps for running on these devices in the first place. If you can think of anything genuinely useful for a significant number of people that wouldn't be covered by such provisions I'd be interested to know.

Technorati Tags: , , ,

PrintView Printer Friendly Version

EmailEmail Article to Friend

References (1)

References allow you to track sources for this article, as well as articles that were written in response to this article.

Reader Comments (6)

Location-tracking apps like Google Latitude and FourSquare?

January 31, 2010 | Unregistered CommenterGraemeF

Running the GPS and a background app would be battery intensive.

The scheduled notifications is a great idea.

What about something between scheduled notifications and true multitasking, the ability to have code run on a schedule but with a strict SLA enforced by the OS (you must complete within x microseconds or you will be terminated). But then a way for the user to see and potentially change these scheduled processes just gets too messy and stops the iPad being what it is supposed to be... simples!

January 31, 2010 | Unregistered CommenterJames

Nice article! I covered wrote something similar in my blog last night, although not as eloquently as you!

January 31, 2010 | Unregistered CommenterBennomatic

Other than the aforementioned location based apps, I can't think of a good reason to have background tasks. But I fundamentally disagree with the premise of this article.

The problem is that just because we can't think of something, doesn't mean that nobody ever will. How many people saw the potential of something like twitter the first time they'd used it? How much use did people get out the internet when it was first created? By not creating a system for background applications, the iPhone limits innovation in mobile applications. This is the real problem. (And just to be clear, I agree that simplicity is important. But I also think users will flock to the platform that provides the next killer app, which Apple may be missing out on.)

February 17, 2010 | Unregistered CommenterJason

@GraemeF: maybe - but I think there is already a facility (currently only available to Apple) for your location to be tracked remotely without the need for a background app (or rather the background task is already there).

@Jason It's fine to disagree :-) However I would argue that (a) we've had plenty of experience with both desktop and mobile devices having full multitasking, so scope for new "killer app" categories we haven't thought of that require it is going to be much smaller. (b) There are also other competing devices out there now (albeit with their own problems) and the launch of the iPad is doubtless going to bring out a whole lot more. You can bet there will be devices *very* similar to the iPad but which expose multi-tasking. We'll have a chance to see (1) whether "users will flock to the platform" and (2) whether such a killer app arises.

I totally agree that there are trade-offs here, but my opinion is that they are best balanced in favour of simplicity. For me "simplicity" is a killer app in itself!
As for "limiting innovation" I think it's important to see the big picture here. There are a number of axes along which innovation can be enabled or disabled - and by the nature of innovation it would be foolish for us to think we know which ones they will occur on. Some of these axes run in both directions (ok the analogy is stretching here), so innovation may be enabled in one or the other direction - but not both. It is not possible to enable innovation in every possible direction. I believe that multi-tasking and simplicity run in virtually the opposite directions and *either* could enable innovation - but as I said I don't think anyone can know for sure.

February 18, 2010 | Registered CommenterPhil Nash

Hey Phil,

Great scheduled notification idea!

I came up with another sort of solution to the multi-tasking problem of task switching which I think might even be better and more intuitive than actually switching apps. (no matter how fast app switching is, it's still an inconvenience to the user)

wonder if apple will eventually provide or allow for something similar.

Hope you will give me a critique/feedback,


February 18, 2010 | Unregistered Commenteryitz..

PostPost a New Comment

Enter your information below to add a new comment.
Author Email (optional):
Author URL (optional):
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>