The description of how multitasking worked before iOS 4 is correct. However, iOS 4 isn’t simply constrained to location, VoIP and streaming audio for multitasking. There are, in fact, seven services developers can use. Background audio is one. VoIP is one. Streaming audio is another.
But, there’s more. A slightly tenuous one Apple notes is “push notifications”. I don’t class this as multitasking; it is push notifications - completely separate. Remember, a year ago, Apple were saying (which was a blatant lie) that push notifications were instead of multitasking, so they can’t be the same thing. Local notifications are, and that’s the next service. This allows push-notification-like alerts that do not need a server running, thus no internet connection is needed either. Therefore, alarms and timers can background (making a noise/alert when the time ends), TVGuide.co.uk can alert you of your next episode of Glee extremely easily. Heck, even We Rule could make a noise when your crops are done. This is a multi-purpose service; it doesn’t have one set function (unlike the first three), and has many applications.
The same is true with task completion; something the article blissfully ignores. Task completion lets an app complete a task, the thread is then destroyed as soon as that task ends to save resources. A very good example Apple states is letting photos upload. Enter Flickr, upload 20 photos. Go out of Flickr. Photos continue to upload. That’s multitasking. And that’s not “location data, voice over IP (VoIP), and audio” at all. For more examples, task completion allows for the user to continue to check email whilst waiting for the downloads of songs in Tap Tap Revenge to finish.
The largest flaw of the article is yet to come though.
According to a few developers who talked to pocket-lint.com, don’t hold your breath for multitasking support in all your apps. One developer said “Why would you want to multitask during a game?” I don’t know who this developer was, but I would like to remind him/her: the iPhone is innately a multitasking device. All applications should be ready at all times to exit at the user’s command.
Why? Because the phone might ring.
If the phone rings and I answer it, will your application bring me back to exactly where I was when I left off? It should, but very few applications get this right. With iOS 4, that oversight is going to be much more glaring especially since Apple is promising people that apps can remember where they left off. Starting with iOS 4, if your app doesn’t do that, your customers are going to expect that you are working on a new version that will. Yes, even the gamers. Save your state and bring us back where we left off when we exited your application and you’ll be ahead of most applications.
Umm, that’s the last function of the multitasking solution; fast app switching. That’s why Apple is promising people. In previous versions of iOS, state-saving was the sole responsibility of the developer, but it was possible. The reason it had little use was because it was difficult to implement. It required large rewrites of some codebases, due to the nature of Objective-C classes. Apple has recognized it was an issue, and have responded with a first-party API set to abstract the difficulty to the OS. Apple’s solution (memory caching) is better aswell, allowing for 1:1 instantaneous restore of state. This means games put you right back in your place mid-game, if you got a call, if you got a new email, if you needed to do anything. It works and it’s here; here’s Steve showing it off with a game of Tap Tap (about 4minutes in).
In conclusion, Apple’s implementation of “multitasking” isn’t perfect from a functional perspective (the overall experience is very good though), although it certainly is better than what the article makes it out to be. I agree, the OS needs a background-updater for things like Instapaper, and Marco Arment’s proposal is good. I had a similar idea, utilizing a new type of push notification. This push notification would do nothing user-facing, but push relevant content (such as Instapaper articles) to the device. The OS stores this, and then - once the app is reawakened - informs the app of the new content and let it deal with it. Even a socket link API would do the trick for IMs, so the app doesn’t need to reconnect to it’s streaming server. The socket would be able to be left open but idle, reducing the wait time for the app to interact once the user returns.
Multitasking in iOS 4 is not a magical sparkle pony. It’s a magically sparkly unicorn that is close enough to a pony to reasonably allow Apple to call it a pony for the vast majority of users, when it still has a horn on its head.