Building notes, projects, and occasional rants

Multitasking on Apple mobile devices

In a couple of hours we will get the chance to see what the iPhone OS 4.0 looks like.

In the past few weeks the hot topic seems to be multi-tasking, or to be more precise, the ability to have several third-party apps running at the same time.

I do have an opinion on this but you should note that I don't own any iPhone OS-using devices. No iPhone, no iPod Touch, and still no iPad. So my view on this is purely theoretical.

Usually Apple doesn't give you what you want, or think you want. They look at a problem, and derive their true essence and solve that.

This 2nd derivative approach to problem solving allows for the creation of tools that work outside their primary target area.

I do think that the same will happen with multi-tasking. I do not expect to have the ability to run several UI-based applications at the same time. Personally I don't see a need for that if switching between apps is fast and easy, and each application keeps its state so that you can go back to where you were.

But there are some things that you want to keep doing when your app looses focus. A Pandora client would like to keep streaming music, a IM client would like to keep a connection open, and be notified when there is activity.

Those things are possible if Apple adopts one of Android features: services. Each app can delegate the small parts that it wants to keep on doing to Apple frameworks, and small non-GUI applications.

For example, we can imagine background services for:

  • do a HTTP request, triggered by a push notification: the content would be stored locally on the device, and the app would have access to those blobs when it starts up the next time. Optionally a small non-GUI application could be asked to run to analyze those blobs and provide alerts, badges, or other types of on-the-device notifications;
  • keep a TCP connection open: a SOCKS-style proxy that keeps the device-to-network TCP connection open, and accepts app-to-proxy connections and splices them together. You IM connection can ask this proxy to keep the persistent connection open to the IM server, and when there is activity, start the small non-UI helper to decide what to do next.

There are of course other type of background use cases. You might want to have your GPS position to be sent on a regular basis to a web service, or to be recorded locally. Again, this can be done by a trusted Apple-provided service, that POST's your current position to a app-provided URL, or stores the coordinates on a local log file that the app can later read.

In short, I do expect Apple to give developers ways to do more background tasks, but I don't expect multiple UI-based apps running at the same time.

I guess we will know more in a few hours.