The idea has unmistakable appeal: have yourself frozen and then thawed out years later, fresh as a spring flower and ready for action. Alas, despite the popular myth that Walt Disney's body is awaiting resuscitation in a vault under Disneyland, science hasn't had much luck with suspended animation (Uncle Walt was cremated in 1966). The iPhone has had slightly more success with its own version of the concept, though. Starting with iPhone OS 4.0, the iPhone learned how to "freeze" an app when you quit; when you relaunch it, you pick up exactly when and where you started. As you hop back and forth among apps, you're just switching between screens held in suspended animation, frozen and ready to resume when you are.
Even before this feature was introduced, this freeze/thaw experience was how most people understood the experience of moving between apps. Unlike desktop software that often takes several seconds to quit or launch, an iPhone app quickly makes its entrance and exit, creating the sense that all apps are already loaded and at the ready. It doesn't feel like quitting and relaunching, although that's exactly what's happening. While the iPhone can now sidestep this relaunch by suspending and resuming apps, its cryogenic powers are limited. Not all iPhone or iPod hardware has the horsepower to suspend apps, and even those that do can suspend only so many apps at a time before starting to nudge them out of memory. In both of those cases, returning to an app means launching them all over again. Your audience doesn't care about these technical niceties, though; no matter what's happening under the hood, they just want your app to start up where they left off. When your app launches, it should work hard to give the impression that it's reviving from suspended animation even when it's not.
For developers spinning iPhone code, all of this means that how your app says hello depends on how well it says goodbye. When an app quits, it should hustle to store not only any unsaved data but also information about the state of the app's interface—the view, position, and content currently on display. With that info safely stashed away, the app can restore the interface to its exact state when the app relaunches, giving the impression that it was running behind the scenes all along.
A well-designed launch image is an important piece of this illusion, as you've seen. For apps with several different screen designs, however, a launch image doesn't always help. Apps can have only one launch image, and they can't change them on the fly. Faking the look of your interface during launch works only when the app has a consistent background from view to view. If your app's screens have very different backgrounds or layouts, the launch image may not match up when your app restores the interface, a visually jarring false start. For example, in the scientific calculator app PCalc (page 67), there are several different keyboard layouts, which means it isn't possible to show a satisfying launch image without risking a collision with the wrong layout. Developer James Thomson fell back to displaying the app's icon graphic as the launch image. "Now there was no jarring transition," James says, "but people stared at my splash screen for four seconds before the calculator appeared and it felt like an eternity while they were waiting to start typing. I actually got emails accusing me of having a massive ego because I was making the splash screen stay up for so long."
He developed a clever hybrid solution: before it quits, PCalc takes a snapshot of the current screen and stores the graphic. When the app is launched again, it shows the launch image (the logo splash screen) for less than a second while it quickly fetches the snapshot saved from the last session. Only after planting this accurate place-holder image does PCalc turn to churning through its startup code to get itself up and running, finally replacing the image with the "real" screen when it's done. This sleight of hand gives the effect that the app has started nearly instantly, right where you left off. (Happily, the app even captures the taps that you make on this decoy graphic; nothing happens until the code fully loads, but after it does, the app goes ahead and shows any numbers you tapped in the meantime.) This would be even more ideal if PCalc didn't show the logo image at all. Unfortunately, an app can't replace its own launch image, so the app always has to use the same original graphic—in this case, the PCalc logo image—before it can display the interface snapshot.
Figure 7-16. Because the app has several screen variations, PCalc's launch image can't mimic the app's interface and instead displays a logo (left). This image appears only briefly before being replaced by a screenshot image from the last session (right). On slower hardware, a tongue-in-cheek status message appears while the app finishes loading.