The World Before Multitasking
The first thing that I learned from this is that applicationDidBecomeActive: is being called right after application:didFinishLaunchingWithOptions:. So even before 4.0 it would have been smart to put there any kind of code that you want executed whenever the app becomes active, be it after app start or upon rejecting a phone call.
Not shown on this diagram is the situation that your app is eating up all the system memory and ignores both the level 1 and level 2 memory warnings. In that case the OS will also terminate your app without totally unscrupulous.
The mechanism with WillResignActive and DidBecomeActive is sort of the Backgrounding Lite that has always been there. This occurs whenever some other thing is displayed in front of your app. This could be the UI to accept a phone call or something as benign as the synching screen.
Multitasking ON
Adding multitasking to this flow chart makes it about twice as complex. I probably spent an hour trying to fit it all together with no crossing lines. Another thing that I noticed while doing this is that applicationWillResignActive: is the only delegate method that I could not optimize into a single box, because one use is to show that the app has been interrupted, the other is to the path into the background.
An app built with 3.2 will still go through a short background stage where applicationDidEnterBackground: is called. but then it will be terminated as usual. If the same app is built against a 4.x SDK then it will not go straight from background to being terminated. Instead it will stick around and so will be the debugger. As soon as you tap the app icon again or choose it from the app switcher it is first informed that applicationWillEnterForeground and then applicationDidBecomeActive.
An app that is suspended but still in RAM might be terminated by the OS if memory runs low. But after entering the background there is no longer any delegate method being called, instead the app will receive a KILL signal. This occurs also if the user long-presses the app icon in app switcher and then removes the app from there with the removal button.
Accepting a phone call no longer terminates your app but will send it into the appropriate background mode. Within the background box you see two purple states that the app can be in. All apps are suspended in RAM per default. You might want to slim down your memory footprint to make your app a less likely target for killing if the system runs low on memory.
Only apps that actually require background processing continue to be executing. This requirement is either set in info.plist or by telling the OS that you have a task to complete, like for example a file upload.
The following kinds of activities get to run in true multi tasking behind the foreground app with lesser CPU priority.
- playing music: “App plays audio”
- geo location: “App registers for location updates”
- VOIP: “App provides Voice over IP services”
If your app does one of these things then adding the key to info.plist is all it takes. But be aware that as soon as your app stops doing what it stated it would be doing the OS again will send it to sleep, only to be awakend by another gentle tap by the user.
In background mode you’re advised to stop updating the UI. Especially with OpenGL Apple is really strict. If you app as much as touches OpenGL while in background the app gets killed right away.
There are only two scenarios left where your app’s applicationWillTerminate: will actually be called: if it’s build with an SDK of less than version 4.0 or if you chose to opt out of backgrounding by adding the UIApplicationExitsOnSuspend key to your info.plist.
So, let’s ask the question we’ve been doing all this fuss for: Where should you now put your code to initialize, update or save changes? applicationWillTerminate not being called in the majority of cases makes it a rather bad candidate to save user defaults or data.
Looking at the chart I see applicationDidEnterBackground as the ideal candidate delegate method for saving state. This is also the last method to be called before a regular 4.0 app gets put to sleep and before a possible kill.
For updating data from the web the case is not as clear. You would not want to reload every time the user comes back to your app. Possible applicationDidBecomeActive: is a good place, provided that you only reload data if sufficient time has passed to be able to assume that something new is available.
Only the first loading of data can stay in application:didFinishLaunchingWithOptions: since every call applicationDidBecomeActive: most likely has the data already loaded previously.
Conclusion
Adding fast app switching and multitasking support is quite easy since for the most part you don’t need to do anything. But you WILL have to review the contents of your app delegate methods to see which code has to be moved into one of the other delegate methods now. Clean out applicationWillTerminate: and have a close look at application:didFinishLaunchingWithOptions: to check if you have something in there that needs to be done every time the app becomes active.
These charts come from some experimentation that I did and what I remembered from the WWDC 2010 session videos on multitasking. Potentially there are mistakes or more surprises hidden in there. Please let me know if you find any.
Here’s the chart in PDF format in case you want to print it out and frame it.
source
iOS 4.1 was, as expected, announced during today’s annual September keynote, and includes a slew of bug fixes, and a few new features. 
