Understanding the lifecycle of an iOS app

Understanding the lifecycle of an iOS app

 

An iOS app follows a typical lifecycle (see Figure 1-4). 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. The app
is indeed running (and in the foreground) but will not receive events, so it
can’t interact with anything during this time. The app then transitions to the
active state. Now, the app is making merry, and you and the app are making
sweet music together. 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)
1. After the first initialization of the app, appDidFinishLaunchingWith
Options 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.
2. 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.
3. 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.