In reply to scottdurrant:
Mobile operating systems work in a slightly different way to desktop ones. Much of the responsibility for managing application lifecycles is taken over by ios or android, rather than leaving it to the user.
Where on the desktop you need to be careful about how many applications are open, hogging resources, ios and android are far more restrictive of user applications. The idea being that a user never needs to quit an application – they just switch to the next one they want to use and if resources get sparse, the OS will kill something that's running in the background.
With this idea come state restoration. Because the OS may well arbitrarily kill an application that's running in the background, a user may be a bit perturbed to navigate back to that app in the app switcher, only to find themselves at the opening view – not where they were when they last used the app. So the OS tells the app on launch if it should try to restore its previous state.
Crucially, this only happens if the app was killed by the OS whilst in the background; it will not happen if the user kills the app themself.
So when you activate the app switcher and see at the back of the stack some app you've not used for months, you can be sure it's not using any resources. The system will have killed it long ago. If you activate it, the system will launch it and tell it that it should restore its previous state. Whether it does that or not is up to the developer, but I think it's easier in android from what martin has told me.