How to Follow the Lifecycle of an iOS App
An iOS app follows a typical lifecycle. At the beginning, the app is simply an executable; it’s not running, lying patiently in wait for a user to click its icon. When the app starts, it goes through numerous initialization steps. During this transitory period, the app is in the inactive state.
Remember the app is indeed running but will not receive events, so it can’t interact with anything during this time. The app then transitions to the active state. This active state is the app’s useful state.
At some point — mostly when another app starts, say, a phone that’s triggered by an incoming call — the iOS runtime will put your app in the background. At this point, the app is in the background state.
Most apps stay in this state for a short time before being suspended. However, an app could request extra time to complete some processing (such as saving its state into a file for use the next time it starts).
In addition, an app meant to run in the background will enter and stay in this state. Note that apps in the background can and do receive events, even though they don’t have a visible user interface.
An app in the suspended state isn’t running code; however, it is using power and the processor. The system moves an app to this state whenever it needs to further conserve resources, and does so without notifying the app. If memory runs low, the system may purge the app to create more space.
As the app transitions through its states, specific methods of the app (that is, code that you wrote) are invoked as explained here.
After the first initialization of the app, appDidFinishLaunchingWithOptions is called, which in turn invokes the portion of the app’s code that sets up its user interface.
The user then sees the app. The app now sits in an event loop, where it waits for user interactions.
When a user interacts with the app, an event is triggered, and a callback method tied to the event is invoked. Most often, the callback method consists of code written by the app’s developer, although it could be reusable code provided as part of the iOS framework.
Once the callback method is done, the app goes back to its event loop. This sequence of actions (of events triggering callback methods) proceeds until the app receives an event that causes it to either shut down or go into the background state.