iOS App Life Cycle – Scene-based life-cycle events for iOS 13+

iOS app development is a constantly evolving field, with each new release of the operating system introducing new features and capabilities. One of the most significant changes in recent years has been the move towards a scene-based life cycle model for iOS apps. This new model, which was introduced in iOS 13, has important implications for developers, particularly those who are building complex, multi-window apps.

In this blog post, we will explore the iOS app life cycle in depth, focusing specifically on the scene-based model introduced in iOS 13+ and clear up some confusions at the end.

What is the iOS App Life Cycle?

The iOS app life cycle refers to the set of events that occur from the moment a user launches an app to the moment they close it. These events include things like app launch, backgrounding, foregrounding, and termination.

Prior to iOS 13, the app life cycle was based on a single window. This meant that when a user opened an app, they were presented with a single window that contained all of the app’s functionality. When the app was backgrounded or terminated, the entire app was suspended or closed.

What is the Scene-Based Life Cycle Model?

With the introduction of iOS 13, Apple introduced a new scene-based life cycle model. This model is designed to support multi-window apps and provide more flexibility for users.

Under the scene-based life cycle model, an app can contain multiple scenes, each of which is associated with a separate window. This means that when a user opens an app, they can choose to open one or more scenes, each of which contains a different subset of the app’s functionality.

When a scene is backgrounded or terminated, only that specific scene is suspended or closed. This means that the user can continue to use other scenes within the app, even if one of them is no longer in use.

Scene vs Scene Session

In app development, a Scene refers to a unique instance of the user interface that’s represented by a UIScene object. To manage the Scene’s lifecycle as the user interacts with it, a UIWindowScene is typically used to oversee one or more windows containing the UI.

On the other hand, a Scene Session represents the Scene’s model, including its configuration and the saved state of the user’s interactions. Scene Sessions are used by the system to manage Scenes in your app, enabling Scenes to be connected and disconnected from their sessions.

Scene Delegate vs App Delegate

In iOS, the Scene Delegate and App Delegate are important objects that are responsible for managing the lifecycle and events of an app.

The App Delegate is the central point of an iOS app’s lifecycle. It is responsible for handling system events and for managing the overall state of the app. When an app is launched, the system creates an instance of the App Delegate and calls its methods, allowing the app to perform any necessary setup tasks. The App Delegate is also responsible for responding to certain events, such as when the app is put into the background or brought back to the foreground.

On the other hand, the Scene Delegate was introduced in iOS 13 as a way to manage multiple windows and scenes within an app. A Scene represents a single instance of an app’s user interface, while a Scene Delegate manages the lifecycle events of that Scene. The Scene Delegate is responsible for creating and configuring the Scene, and for responding to events such as when the Scene is about to become active or inactive. The Scene Delegate is responsible for managing the lifecycle events and state restoration of an app on a per-scene basis. To accomplish this, the Scene Delegate typically conforms to the UIWindowSceneDelegate protocol, which enables it to manage windows within the app. The window property of the Scene Delegate replaces the deprecated keyWindow property of the UIApplicationDelegate subclass, which was used to store the app’s key window. As with Scenes, it’s not possible to create a Scene Delegate object directly. Instead, you need to specify its class name in the Info.plist file or pass it dynamically during Scene Session configuration. This ensures that the system can manage the Scene Delegate properly and respond to its events as needed.

How do Scene-based Life-cycle Events Propagate?

If your app has different parts called “scenes,” each scene can do its own thing at different times. A scene is like a separate screen that you can open, close, or switch between. You can have more than one scene for the same app, and you can choose to show or hide them. Since each scene has its own way of working, it can be in a different state. For example, one scene might be on the screen while the others are in the background or paused. When you or the device asks for a new scene, the app creates it and puts it in a state where it’s not connected to anything(Unattached state). When you open a scene that you asked for, it quickly comes to the front and appears on the screen(Foreground Active). But if the device needs to do something important, like receiving a call, the app goes to inactive state(Foreground Inactive). However, app might do some calculation in the background(Background state). When you close the app(Suspended state), the scene might get closed to save space.

The lifecycle of a UIScene can be divided into four main states basically:

• Unattached,
• Suspended,
• Background,
• Foreground (Active or Inactive).

Unattached

The Unattached state is the initial state of a Scene when it’s created, and it means that the Scene is not yet attached to a session. In this state, the Scene is not visible to the user, and its UI is not being displayed. Every UIScene begins its lifecycle in the unattached state, which means it’s not currently associated with any session. From this state, there are two possible routes that a Scene can take. If the Scene is requested by the user, it can transition into the foreground state, which means its UI becomes visible to the user. Alternatively, if the Scene is requested by the system to process an event, it can stay in the background or suspended state.

It’s important to note that the system may detach a Scene from the background or suspended state at any time to reclaim system resources. This means that the Scene’s UI may no longer be visible to the user, and its background activities may be paused until the Scene is re-attached to a session.

Suspended

The Suspended state occurs when the Scene is attached to a session but is not currently visible to the user. In this state, the Scene’s UI is not being updated, and its background activities are paused to save system resources. When a UIScene is in the suspended state, it’s not actively performing any work and can be thought of as being in a sleeping state. This means that its background activities are paused, and the Scene is not using any system resources. From the suspended state, a Scene can either be detached or woken up to perform certain tasks. When a Scene is woken up, it transitions into the background state to perform background tasks, such as downloading data or updating content. These tasks are typically performed without the user’s knowledge, and the Scene’s UI remains hidden from the user.

Background

The Background state occurs when the Scene is still attached to a session but is not currently the foreground Scene. In this state, the Scene’s UI is not visible to the user, but its background activities are still active and can continue to execute. When a UIScene is in the background state, it’s not visible to the user, and its functionality is limited to specific tasks that it’s allowed to perform. From the background state, a Scene can take three different routes: it can become unattached, it can become suspended, or it can move to the foreground.

Although the Scene’s UI is not visible to the user, it can perform a limited set of background tasks, such as receiving location updates and processing push notifications. These tasks are typically performed without any user input and are essential for maintaining the app’s functionality

Foreground

The Foreground state occurs when the Scene is the current foreground Scene. It can be either Active or Inactive. When the Scene is Active, its UI is visible to the user, and its background activities can continue to execute. In contrast, when the Scene is Inactive, its UI is still visible, but the Scene is unable to respond to user interactions or execute background activities. When a UIScene is in the foreground state, it’s presented to the user, and its UI is visible and accessible. When a Scene is in the foreground-active state, it’s actively processing both system and user interaction events. This means that the Scene’s UI is visible and the user can interact with it, and the Scene is responsive to any system-level events, such as notifications and background tasks.

However, the foreground-active state can be interrupted if the Scene receives a phone call. When this happens, the Scene moves into the foreground-inactive state, where it’s not receiving any system or user interaction events. This is important to ensure that the Scene is not disrupted by external events and can properly transition between different states.

What are Scene-based Life-Cycle Events?

The scene-based life cycle model introduces a new set of events that occur during the life cycle of an iOS app. These events are specific to each scene and are designed to provide more granular control over how the app behaves.

The scene-based life-cycle events include:

Connecting and disconnecting the scene

Scene Will Connect to Session: This event occurs when a new scene is created and is about to connect to the app’s session. At this point, the app can perform any setup or initialization tasks that are specific to the new scene.

optional func scene(
    _ scene: UIScene,
    willConnectTo session: UISceneSession,
    options connectionOptions: UIScene.ConnectionOptions
)

Scene Did Disconnect: This event occurs when a scene is removed from the app’s session. At this point, the app can perform any cleanup or teardown tasks that are specific to the removed scene.

optional func sceneDidDisconnect(_ scene: UIScene)

Transitioning to the foreground

Scene Will Enter Foreground: This event occurs when a scene has entered the foreground. At this point, the app can perform any tasks that are specific to the foregrounded scene, such as displaying a notification or starting a new activity.

optional func sceneWillEnterForeground(_ scene: UIScene)

Scene Did Become Active: This event occurs when a scene has become active. At this point, the app can perform any tasks that are specific to the activation of the scene, such as starting an animation or resuming a video.

optional func sceneDidBecomeActive(_ scene: UIScene)

Transitioning to the background

Scene Will Resign Active: This event occurs when a scene is about to resign its active status. At this point, the app can perform any tasks that are specific to the deactivation of the scene, such as stopping an animation or pausing a video.

optional func sceneWillResignActive(_ scene: UIScene)

Scene Will Enter Background: This event occurs when a scene is about to enter the background. At this point, the app can perform any tasks that are specific to the backgrounding of the scene, such as saving user data or stopping

optional func sceneDidEnterBackground(_ scene: UIScene)

How much time app can run in the background?

According to apple, only specific app types are allowed to run in the background:

• Apps that play audible content to the user while in the background, such as a music player app
• Apps that keep users informed of their location at all times, such as a navigation app
• Apps that support Voice over Internet Protocol (VoIP)
• Newsstand apps that need to download and process new content
• Apps that receive regular updates from external accessories

Other than the specific things an app can do in the background, there is also a way for an app to continue working for a very brief time, which is explained in the “Executing a Finite-Length Task in the Background” section of the documentation. After that short time, the app can either let the system know it’s finished and then be suspended, or the system can forcefully shut it down.

What is the difference between background and suspended state in iOS?

The iOS system has two states for apps when they are not currently being used by the user: background and suspended.

When an app is in the background state, it can still execute code and perform tasks. For example, if you upload a short on Youtube and switch to another app, YouTube can still complete the upload in the background. However, being in the background state doesn’t necessarily mean the app is suspended. An app can ask to stay in the background for a short period of time to complete tasks like uploading a video or finishing a network request. After that, the app will either go into a suspended state or be forced to close by the system.

When an app is in the suspended state, it is not executing any code and is just stored in memory. This state is also considered to be in the background. The system moves apps to the suspended state without notifying the user beforehand.

Read more from Apple documentation.

Written by

ISHTIAK AHMED

Twitter LinkedIn

---

Get Ready to Shine: Mastering the iOS Interview

• Uplift iOS Interview - A Comprehensive Guide to iOS Interview
• iOS Dev Kit - Cheat Sheets, Posters and Infographics

---

Enjoying the articles? Get the inside scoop by subscribing to my newsletter.

Get access to exclusive iOS development tips, tricks, and insights when you subscribe to my newsletter. You'll also receive links to new articles, app development ideas, and an interview preparation mini book. Your email address will only be used for the purpose of sending the newsletter and will not be shared with third parties or advertisers. Rest assured that we value your privacy and will not spam your inbox.