Introduction
This article explains the life cycle of a typical iOS application on iOS4 and iOS3. After going through this, one can get a fair idea about various transition states of App.
Background
iOS 4 supports applications execution in the background, however till iPhone OS 3.x (iOS 3.x) background execution was not supported.
Because of Background execution functionality, there is major change in the application’s lifecycle on iOS4. While designing an application for iOS4, handling of new transitional states must be taken in consideration.
Application Life Cycle on iOS
The application life cycle constitutes the sequence of events that occurs between the launch and termination of application. In iOS, the user launches application by tapping its icon on the Home screen. Shortly after the tap occurs,
- System displays some transitional graphics
- Proceeds to launch your application by calling its main function
From this point on, the bulk of the initialization work is handed over to UIKit, which loads the application’s user interface and starts its event loop.
There is a predefined sequence of events that occurs from the time of application start up to the time it quits.
At key points in the application’s life, UIKit sends messages to the Third Party application's delegate object to let it know what is happening.
In iOS 4 and later, Third Party Applications now remain resident in memory by default after they are quit. This means that subsequent launches of the application may not always involve starting the application from scratch. Hence applications designed on iOS4 should be able to handle several different state transitions.
Here is the depiction of events on iOS4:
Till iOS 3, At the time of quit message application use to be terminated, here is the depiction of Applications life cycle till iOS 3:
There were only two possible states of third party application in iOS 3:
But because of background applications support in iOS 4, following are the possible state of any third party application:
- Not running: The application has not been launched.
- Inactive: The application is running in background but not receiving events.
- Active: The application is running in foreground and is receiving events.
- Background: Most applications enter this state briefly on their way to being suspended. However, an application that requests extra execution time may remain in this state for a period of time. In addition, an application being launched directly into the background enters this state instead of the inactive state.
- Suspended: The application is in the background but is not executing code. The system moves application to this state automatically and at appropriate times.
While suspended, an application is essentially freeze-dried in its current state and does not execute any code. During low-memory conditions, the system purges suspended applications without notice to make more space for the foreground application.
After knowing these facts, there could be some obvious questions like...
How a Background iOS Application Gets Resumed in Foreground?
When the user launches an application that currently resides in the background, the system moves it to the inactive state and then to the active state. This results in calls to the following methods of the application delegate:
applicationWillEnterForeground applicationDidBecomeActive
How an iOS Application Can Opt Out of Background Execution?
An application can explicitly opt out of the background execution model by adding the UIApplicationExitsOnSuspend key to application’s Info.plist file and setting its value to YES. When an application opts out, it cycles between the not running, inactive, and active states and never enters the background or suspended states.
Opting out of background execution is strongly discouraged but may be preferable under certain conditions.
How an iOS Application Responds to Interrupts like SMS, Incoming Call, Calendar, etc.?
When the Active application is interrupted by an incoming phone call, SMS, or calendar notification, the application moves to the inactive state temporarily.
It remains in this state until the user decides whether to accept or ignore the interruption.
- If the user ignores the interruption, the application is reactivated.
- If the user accepts the interruption, the application moves into the suspended state.
History
- 29th October, 2010: Initial post
