On multitasking, sparkle ponies, and saving state
In an article for TUAW called Multitasking in iOS 4 is not a magical sparkle pony, TJ Luoma gives a pretty good overview of some of the multitasking features available in the new OS and why they might not satisfy all users’ needs without extra effort from developers.
In rebuttal to TJ’s piece, Benjamin Mayo writes:
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.
There’s a big overstatement here, and it’s one that I think needs pointing out. What Mayo is talking about is somewhat complex, but I’ll try to break it down.
Under the current iPhone OS (version 3.2) and earlier, when you hit the Home button, that’s it: the running app is terminated. But first, it’s given a few seconds to perform cleanup tasks — the time limit is enforced by the OS — and during those few seconds, some of the better apps save their state: they write out some data to the user preferences database, or to a file in their storage area. That data contains a representation of the current arrangement of the user interface: which screen you’re on, your scroll position, any text you may have typed into a text field, etc. The next time the app is launched, it reads back the saved data and uses it to rebuild its interface to appear as though you never left.
For example, Twitter for iPhone (formerly Tweetie 2) uses this state-saving mechanism, and for that reason alone it’s one of my favorite apps. When the phone rings, or when I have to leave for a moment to check something in another app, I can be confident that I’ll come right back to where I was before, no matter how far away from the default “top of my timeline” view I had navigated.
What iOS 4.0 does with its Fast App Switching feature — the kind of multitasking you get “for free” just by recompiling your app with the 4.0 SDK — is to change the behavior of the Home button. In 4.0, on devices that support multitasking, pressing Home won’t terminate the running app but rather suspends it. It stays in memory as long as there’s room, and when you switch back, there’s no delay while it relaunches: you’re instantly right back where you were. (This is essentially the “freezing in carbonite” idea I came up with five months ago, because I am obviously some kind of super genius.) So in many situations, apps will seem to remember where you were when you switch back to them.
But Mayo is wrong about one thing: OS 4.0’s Fast App Switching does not make it any easier for developers to do this position-remembering trick than 3.2 did. The reason is that apps can go from suspended to terminated at any moment, without being given any additional processing time to clean up or save state. This isn’t an exceptional case: this is the normal way apps are now terminated. When the system needs memory — and memory is very limited on iOS devices — it simply starts terminating suspended apps to reclaim it. So any app that doesn’t want to lose data will have to perform that state-saving operation as soon as it’s suspended, because that will be its last chance.
In other words, in iOS 4.0, developers will still have to make decisions about what data to save and how and where to save it, and they will still have to write all the code to actually do that save-and-restore. In fact, it’s even more important that they do so under 4.0 than before, because if they don’t, users will notice it now. Under 3.2 and earlier, an app that didn’t save its state would just relaunch in some default state every time — you learned to rely on that, and seeing clever apps like Tweetie 2 remember your place was an unexpected bonus. But under 4.0, a non-state-saving app will sometimes resume where it left off and sometimes not (because it happened to get terminated while suspended). Inconsistent behavior like this won’t just be confusing; it will actually seem broken.
Developers, take note: with iOS 4.0 and Fast App Switching, Apple isn’t doing your work for you. They’re telling you that you must begin saving your state. If resume-from-suspend isn’t identical in appearance to relaunch-from-terminate, then you have a bug to fix, and your users will know it.
