Ian Bogost - Latertasking

my affiliations

Ian Bogost - videogame theory, criticism, design

about me

contact

blog

Latertasking

How multitasking really works on iOS 4

June 27, 2010

short url: http://bogo.st/ec

tags: Apple , computing , iPhone

Despite the fact that I develop for iPhone, I can't tolerate using beta versions of the OS on my personal device. So it was only last week that I I installed iOS 4 on my iPhone last week. Ever since, I've been trying to grasp how the widely-anticipated multitasking feature really works. I understood that actually running a background thread would require a recompile to take advantage of the new OS's facility for keeping a program running while inactive. But I had also understood that all apps would remain memory resident when dismissed, such that they'd pick up where they left off. The OS, I further understood, would manage memory and dismiss unused apps in the background to free it up if necessary.

But that's not what happened in practice. When I ran apps listed in the fast switch menu, they were clearly restarting. Thanks to pointers from Nick Seaver and John Marstall, I read this helpful article by Matt Neuburg, which clarifies things:

It turns out that in order to participate in multitasking and allow itself to be suspended, every app must be recompiled for iOS 4. An app that doesn't appear to behave any differently when you resume it on iOS 4 from how it behaved when you relaunched it on earlier versions of the system simply hasn't been recompiled yet. That, as a moment's reflection will show, would be the vast, vast majority of apps!

Indeed, if you read Apple's page on multitasking on iOS4, an easily overlooked asterisk that makes this behavior clear (*Multitasking is available with apps that have been developed to work with iOS 4). But I don't think I'm the only one who was confused. I also don't really understand why the OS couldn't keep pre-iOS 4 apps memory resident.

As Neuberg points out, the only way multitasking will work systemically in the way Apple's promised is if all or most of the 200,000 apps available are recompiled for the new OS and resubmitted for Apple approval. That's unlikely for a number of reasons. To name a few: many (most?) apps are hobbyist affairs or failed to make enough money for their developers to justify supporting them; updates take time to complete and, moreso, to get approved; many developers haven't upgraded to 3GS or 4G devices and thus can't test their apps.

What does all this add up to? I'd argue this: while iOS4 might have the technical capability to multitask, the application ecosystem Apple has developed for the device insures that it can't possibly behave in the way one would expect. That might change, eventually, as the platform evolves around the new OS, although it does draw attention to a little-critiqued aspect of the iPhone platform: many of those 200,000 apps approach uselessness. For one part, many started that way, but for another part, Apple's insistence on upgrading the OS and device so rapidly makes it hard for all but the most successful apps to keep operating effectively.

For now, since pre-iOS 4 apps are not really backgrounded, the fast switch menu is really just a list of recently used apps. That's somewhat useful, I suppose, but it's hardly "multitasking." How could we more accurately describe the feature as it really operates?

Multitasking means that many programs can run simultaneously and continuously. When recompiled for iOS 4, apps get backgrounded so they can be restored later, but they don't continue running unless programmed specifically to do so. When not rebuilt for the new OS, apps close but remain slightly more conveniently nearby. If we use a desktop metaphor, both flavors of multitasking are more like moving some papers from the center of your attention to the edge of the desk, close at hand for later retrieval.

That in mind, iOS4's behavior might be best characterized as latertasking. Rather than putting apps away entirely, they remain close by but inactive, like a dogeared book on the desk rather than a closed book on the shelf. A convenience, no doubt, but hardly the expectation most probably have of the word "multitasking" from the world of desktop computing. Call it Apple hype if you'd like, but I suspect Steve Jobs would argue that it's not spin, but peeling, a necessary step in turning bland, boring apples into sweet and spicy apple pie.

Comments (5)

Want to comment on your site? The trackback URL is http://www.bogost.com/mt/mt-tb.cgi/2081 Want to comment on my site? Use the comment form below.

I fail to understand the seeming groundswell of heartache around this issue. I'm not saying that you're response isn't a leveled observation, but there are plenty out there that aren't.

I had thought the Jobs was fairly transparent about how the suspended app state would work during his keynote at the iOS4 beta event. It probably got lost in the whole Flash BS, but he did say that they were opening up the advanced save/suspended state that until then was only available to Apple 1st party apps and that apps would have to be recompiled in a similar fashion to the iOS3 launch.

The piece of it I've yet to figure out because I haven't been pushing code lately is are the background APIs meant to replace push notifications or work hand-in-hand with them...

Dakota Reese Brown on June 27, 2010 12:06 PM

The local notifications and background API work hand-in-hand with the push notifications. The push notifications allow your device to get events from external sources (or internal sources, but routed through an internet-attached server). Local notifications allow your device to notify itself (for example, an application can run in the background, then notify you when it's complete) even if you're not able to get to the internet. The background APIs allow a limited set of functionality to be run in the background while other applications are running in the foreground.

On the multitasking aspects, the bar you get when you double-click the home button is just pure UI; there is no functionality there. You get the same ability to relaunch and quit apps through Springboard and "shaky icon mode". My main concern with the multitasking was that it would be too intrusive, requiring a lot of chrome to make it work. Apple did a decent job with this, but then kind of messed it up (in my opinion) by adding the recent applications bar. That multitasking is happening should essentially be invisible to the user, only apparent when they see the (-) badge in shaky icon mode.

From the developer's side, I'm pretty happy with it. In particular, I like the fact that, because I always program a suspend to save state as if the app were quitting (what would happen otherwise if the phone ran out of power while the app were suspended?), I don't really need to rewrite anything to run it on iOS4, just recompile it. I can take advantage of the new UIs to save state more completely and with less code, but I don't have to "fix" my earlier programs.

Jeff Medcalf on June 27, 2010 12:50 PM

@Dakota
I don't watch the Jobs keynotes (really), so I wouldn't know. In any case, it seems to me that one shoudn't have to watch developer conference talks to understand the features of the products, yes?

@Jeff
I think the idea of a recent applications interface is fine and maybe even convenient, and it's nice to be able to switch to an app from within another app. The interface didn't confuse me, but what it represented sure did. I still wish I understood why pre-iOS4 apps can't remain memory resident in the background.

Ian Bogost on June 27, 2010 1:55 PM

Solid points, Ian. I'd only offer that I'm slightly more optimistic that most of the apps you or I use will get recompiled and updated sooner rather than later. Like Jeff, my understanding is that developers who want to do the bare minimum can just update Xcode and rebuild the app using iOS 4 as the base SDK.

As to why this is required at all, I'm just guessing but I think it may be because the OS sends a "you are about to be suspended, so unregister from Bonjour etc." notification to the app before it does so. This is a new event that pre-iOS 4 apps wouldn't know how to handle.

John Marstall on June 27, 2010 2:49 PM

@John
In some cases, it's actually much harder to recompile on a new version of the OS than it might seem. I had this experience going from 2.0 to 3.0; some of our apps wouldn't "just recompile"... considerable reengineering was required. I don't know if that's the case 3.x-4.0, but it is important to recognize that the new OS targets are sometimes not as seamless as they ought to be. Nevermind the whole app approval thing.

As for the about to be suspended message, one of the beautiful things about ObjectiveC is that messages can be handled or ignored. Now, it's still possible that suspending networking or other sorts of systems could break some apps, but I'd still call it an engineering mistake given the way Cocoa is designed to work. I suspect Apple does some of these things just to encourage developers to update to the new OS, which is understandable but also disappointing. The amount of upkeep required to be an iPhone app developer is overwhelming, particularly when the average app isn't financially sustaining.

Ian Bogost on June 27, 2010 3:26 PM

Name:
Email:
URL:
	Remember me for next time?
Comments: (HTML is allowed, but comments with URLs will be held for moderation to avoid spam.)