Introduction
The current state of your app determines what it can and cannot do at any time. For example, a foreground app has the user's attention, so it has priority over system resources, including the CPU. By contrast, a background app must do as little work as possible, because it is offscreen. As your app changes from state to state, you must adjust its behavior accordingly.
When your app's state changes, UIKit notifies you by calling a method of the appropriate delegate object,
- In iOS 13 and later use UISceneDelegate objects to respond to lifecycle events in a scene-based app.
- In iOS 12 and earlier, use the UIApplicationDelegate object to respond to lifecycle events.
Note
If you enable scene support in your app, iOS always uses your scene delegates in iOS 13 and later. In iOS 12 and earlier, the system uses your app delegate.
Response to Scene-Based Lifecycle Events
If your app supports scenes, UIKit delivers separate lifecycle events for each. A scene represents one instance of your app's UI running on a device. The user can create multiple scenes for each app, and show and hide them separately. Because each scene has its own lifecycle, each can be in a different state of execution. For example, one scene might be in the foreground while others are in the background or are suspended.
Important
Scene supports is an opt-in feature. To enable basic support, add the UIApplicationSceneManifest key to your app's Info.plist file as described in Specifying the Scenes your App Supports.
The following figure shows the state transitions for scenes. When the user or system requests a new scene for your app, UIKit creates it and puts it in the unattached state. User-requested scenes move quickly to the foreground, where they appear onscreen. A system-requested scene typically moves to the background so that it can process an event.
Use scene transitions to perform the following tasks,
- When UIKIT connects a scene to your app, configure your scene's initial UI, and load the data your scene needs.
- When transitioning to the foreground-active state, configure your UI and prepare to interact with the user
- Upon leaving the foreground-active state, save data and quiet your app's behavior.
- Upon entering the background state, finish crucial tasks, free up as much memory as possible, and prepare for your app snapshot.
- At scene disconnection, clean up any shared resources associated with the scene.
- In addition to scene-related events, you must also respond to the launch of your app using your UIApplicationDelegate object.
Respond to App-Based Lifecycle Events
In iOS 12 and earlier, and in apps that don't support scenes, UIKit delivers all lifecycle events to the UIApplicationDelegate object. The app delegate manages all of your app's windows, including those displayed on separate screens. As a result, the app state transitions affect your app's entire UI, including content on external displays.
The following figure shows the state transitions involving the app delegate object. After launch, the system puts the app in the inactive or background state, depending on whether the UI is about to appear onscreen. When launching to the foreground, the system transitions the app to the active state automatically. after that, the state fluctuates between active and background until the app terminates.
Use app transitions to perform the following tasks,
- At launch, initial your app's data structure and UI.
- At activation, finish configuring your UI and prepare to interact with the user.
- Upon deactivation, save data and quiet your app's behavior.
- Upon entering the background sate, finish crucial tasks, free as much memory as possible, and prepare for your app snapshot.
- At termination, stop all work immediately and release any shared resources.
There are some following methods names when an application starts,
- application: willFinishLaunchingWithOptions: -> Bool. This method is intended for the initial application setup. Storyboards have already been loaded at this point but state restoration hasn't occurred yet.
- application: didFinishLaunchingWithOptions: -> Bool is called next. This callback method is called when the application has finished launching and restricted state and can do final initialization such as creating UI.
- applicationWillEnterForeground: is called after application: didFinishLaunchingWithOptions: or If your app becomes active again after receiving a phone call or system interruption.
- applicationDidBecomeActive: is called after applicationWillEnterForeground: to finish up the transition to the foreground.
- applicationWillResignActive: is called when the app is about to become inactive (for example, when the phone receives a call or the user hits the Home button).
- applicationDidEnterBackground: is called when your app enters a background state after becoming inactive. You have approximately five seconds to run any tasks you need to back things up in case the app gets terminated later or right after that.
- applicationWillTerminate: is called when your app is about to be purged from memory.
Both application
WillFinishLaunchingWithOptions: and application:didFinishLaunchingWithOptions: can potentially be launched with options identifying that the app was called to handle a push notification or url or something else. You need to return true if your application can handle the given activity or url.
I hope the above article will help to understand the concepts of the application lifecycle.
Thank you for reading!! If you like my article please share with others.