App lifecycle and background execution

The lifecycle in SwiftUI: three phases

The modern API is one environment value and a modifier:

@main
struct CheckoutApp: App {
    @Environment(\.scenePhase) private var scenePhase
    @State private var model = AppModel()

    var body: some Scene {
        WindowGroup { RootView(model: model) }
            .onChange(of: scenePhase) { _, phase in
                switch phase {
                case .active:      model.refreshIfStale()      // came to foreground
                case .inactive:    model.pauseSensitiveWork()  // visible, not interactive
                case .background:  model.saveEverything()      // may be suspended/killed next
                @unknown default:  break
                }
            }
    }
}

The three phases, with the job of each:

• .active — foreground, receiving events. On entry: refresh stale data, resume timers/animations, re-check permissions the user may have changed in Settings.
• .inactive — visible but not interactive: mid-transition, system dialog up, app-switcher swipe in progress. On entry: pause gameplay/video; this is also where privacy-sensitive apps put up their cover so the app-switcher snapshot hides content.
• .background — off screen. This is a deadline: you have seconds before suspension, and no promise of ever running again — the next event may be termination without notice. Save all user state now.

That last sentence is a rule with a name worth using: background = save point. Apps that lose a half-composed message when the user answers a phone call skipped it; nothing else on this page matters if this part is wrong. (And note what phases don't tell you: .background fires equally for "checking Messages for five seconds" and "gone for a week" — persist as if it's forever, every time.)

The suspension timeline, and the grace period

What actually happens after the swipe:

foreground ──▶ .inactive ──▶ .background ──▶ [~seconds] ──▶ SUSPENDED ──▶ maybe TERMINATED
                                              │                             (memory pressure,
                                              └── beginBackgroundTask ──┐    no notice)
                                                  extends to ~30s        │
                                                  expiration handler ────┘

beginBackgroundTask(expirationHandler:) requests a short extension — historically minutes, now on the order of ~30 seconds — for finishing an operation already in flight: flushing the outbox, completing a save, closing a file cleanly. The contract has two teeth: you must call endBackgroundTask when done (leaking the token gets the app killed for overrunning), and the expiration handler must end the work immediately when the system calls time. It is a grace period, not a work session.

For anything bigger than the grace period, you hand the work to the system:

The two rows interviews probe:

Background URLSession — URLSessionConfiguration.background(withIdentifier:). Transfers run in a system daemon, surviving your suspension and termination; when they finish, iOS relaunches the app in the background and calls the session delegate. The integration quirk everyone hits: results arrive via the delegate (not async closures), and the app must reconnect to the session by the same identifier on relaunch.

BGAppRefreshTask — the "check for new content periodically" API, and the one whose expectations are most often wrong. You submit a request with an earliestBeginDate; the system decides if and when it runs, weighing user habits, battery, and your app's track record. It is not a timer, not cron, and heavy users get more runs than abandoned installs. Design so refresh is a bonus, never a dependency — the offline-sync lesson's outbox already made foreground drains correct; background refresh just makes them fresher.

Both traces end with unsaved edits at risk: 0 — because the save happened at the phase transition, before any grace-period gamble. The flush racing the expiration handler is the outbox drain, which was already safe to interrupt (idempotency keys, persistent queue) — the sync lesson's design decisions are what make this lesson's deadlines survivable.