App Lifecycle in SwiftUI
SwiftUI replaced the old UIKit AppDelegate/SceneDelegate dance with a declarative entry point built around two protocols: App and Scene. An App is the root of your program — the thing the operating system launches — and it owns one or more Scenes, each representing a piece of UI with its own lifecycle (a window, a document, a widget configuration). Rather than overriding delegate methods to react to launch, backgrounding, or termination, you observe a single environment value, scenePhase, and branch your logic off its three cases: active, inactive, and background. This model is smaller in surface area than UIKit's lifecycle but it still maps onto the same underlying iOS process states, so understanding one helps you understand the other.
Cricket analogy: Just as MS Dhoni's captaincy relied on reading match phase — powerplay, middle overs, death overs — rather than issuing a separate instruction for every ball, scenePhase collapses many delegate callbacks into three states: active, inactive, background.
@main
struct RecipeApp: App {
@Environment(\.scenePhase) private var scenePhase
@State private var store = RecipeStore()
var body: some Scene {
WindowGroup {
RecipeListView()
.environment(store)
}
.onChange(of: scenePhase) { oldPhase, newPhase in
switch newPhase {
case .active:
store.resumeSync()
case .inactive:
store.pauseAutosave()
case .background:
store.persistToDisk()
@unknown default:
break
}
}
}
}The App and Scene protocols
Every SwiftUI app has exactly one type marked @main that conforms to App and implements a computed body of type some Scene. WindowGroup is the most common scene builder — on iOS it produces the app's single window; on iPadOS and macOS it can produce multiple windows of the same kind. Other scene types include DocumentGroup for document-based apps, Settings for a macOS preferences window, and WidgetConfiguration for widget extensions. Because App and Scene are just protocols with a body, you can compose custom initialization logic — such as configuring third-party SDKs or dependency containers — directly in the App type's init(), which runs once at process launch, before any view appears.
Cricket analogy: Just as a team has exactly one captain, like Rohit Sharma, who sets the batting order once before play begins, a SwiftUI app has one @main App type whose init() configures SDKs once at launch, before any WindowGroup or widget scene appears.
scenePhase and its three states
scenePhase is an environment value of type ScenePhase, read with @Environment(\.scenePhase). It has three cases. active means the scene is in the foreground and receiving events — the normal running state. inactive is a transitional state: the app is visible but not receiving events, which happens momentarily during transitions, when a system alert or the app switcher overlays the UI, or right before backgrounding. background means the scene is not visible at all; the app may still run briefly to finish work (e.g., inside a background task) before being suspended or, eventually, terminated by the system to reclaim memory. Because termination is not guaranteed to fire any callback, background is the correct place to persist critical state — treat it as your last reliable checkpoint.
Cricket analogy: Just as a batsman must complete a run before the throw arrives, since a bad-light stoppage isn't guaranteed to give a clean final call, an app must save state during background — its last reliable checkpoint — rather than waiting for termination.
Reacting to phase changes vs. UIKit delegate methods
In UIKit, you'd override applicationDidBecomeActive, applicationWillResignActive, applicationDidEnterBackground, and similar delegate hooks. SwiftUI condenses these into transitions between the three scenePhase cases, observed with .onChange(of:). A transition from background or inactive into active corresponds roughly to didBecomeActive; active to inactive corresponds to willResignActive; inactive to background corresponds to didEnterBackground. For lower-level hooks that scenePhase doesn't expose — push notification registration, URL scheme handling nuances, or background fetch completion handlers — you can still bridge to an AppDelegate using @UIApplicationDelegateAdaptor inside your App type, letting SwiftUI and UIKit lifecycle code coexist.
Cricket analogy: Just as a modern T20 franchise replaced multiple old-school signals (drinks break, strategic timeout, innings break) with one clear scoreboard state while keeping a manual scorer for edge cases, SwiftUI replaces UIKit's hooks with onChange(of: scenePhase) while @UIApplicationDelegateAdaptor covers edge cases like push notifications.
Think of scenePhase like a traffic light with only three colors instead of a dozen turn signals: green (active), yellow (inactive), red (background). You lose fine-grained detail but gain a model simple enough to reason about correctly in every app, which is usually the better trade.
Don't assume background always leads to termination gracefully — the system can also suspend the process in the background state without further notice and later kill it without calling any more code. Persist essential data as soon as you enter background rather than deferring it, and don't rely on long-running work completing unless you've explicitly requested background execution time.
Multiple scenes and per-scene phase
On iPadOS and macOS, a single App can have multiple WindowGroup instances open simultaneously, and each has its own independent scenePhase — one window can be active while another is inactive. This matters for apps that support multiple windows: state you scope to @Environment(\.scenePhase) is read per-scene, so logic in one window's onChange won't fire for another window's transitions. On iOS, where apps are effectively single-window, this distinction is usually invisible, but code you write for scenePhase should still be written per-scene to remain portable to iPad multitasking.
Cricket analogy: Just as two simultaneous IPL matches on different grounds each have their own independent rain-delay status — one under rain, one still playing — each WindowGroup on iPadOS has its own scenePhase, so one window's onChange won't fire for another window's transition.
- The App protocol (marked @main) is the root of a SwiftUI program and owns one or more Scenes.
- scenePhase exposes three cases — active, inactive, background — read via @Environment(\.scenePhase).
- background is the last reliable checkpoint to persist critical state before possible suspension or termination.
- @UIApplicationDelegateAdaptor bridges to UIKit AppDelegate callbacks that scenePhase does not cover.
- Each scene (window) has its own independent scenePhase, relevant for multi-window iPadOS/macOS apps.
- Treat inactive as a brief, transient state rather than a signal to persist data.
Practice what you learned
1. Which environment value replaces most UIKit AppDelegate lifecycle callbacks in a SwiftUI App?
2. What does the .inactive scenePhase case represent?
3. Why should critical data be persisted when scenePhase becomes .background rather than waiting for termination?
4. How can a SwiftUI App access UIKit-only lifecycle callbacks like push notification registration?
5. On iPadOS with multiple windows open, how is scenePhase scoped?
Was this page helpful?
You May Also Like
App and Scene Structure
Understand how the App and Scene protocols define a SwiftUI application's entry point, window management, and lifecycle across platforms.
SwiftData Basics
Learn how SwiftData lets you model, persist, and query app data using plain Swift types annotated with macros, replacing much of Core Data's boilerplate.
Task and Structured Concurrency
Explore how Swift's Task type creates units of asynchronous work, how structured concurrency establishes parent-child relationships, and how cancellation propagates.
@EnvironmentObject Basics
Learn how @EnvironmentObject injects a shared model into the SwiftUI view hierarchy so deeply nested views can access it without manual parameter passing.