What runs before the first view

The console shows

app:  background -> inactive
app:  inactive -> active
view: inactive -> active

Three lines, and the first surprises most people: the app's phase starts at background. A launch is a move from the background to the foreground, by way of inactive.

The view prints only the last step. By the time the view exists and is watching, the scene is already inactive, so the first change it can see is the one to active.

Two practical points. onChange on the scene fires during launch, so code there that means "the user came back" also runs when the user arrives for the first time — which is usually what you want, but know it. And the phase background at launch is not a quirk of the simulator: an app can be launched into the background by the system, for a background task or a notification, and then it never becomes active at all.

Where this comes from: ScenePhase · App organization — Apple: "The system moves your app’s Scene instances through phases that reflect a scene’s operational state."

Pressing Home printed:

app:  active -> inactive
view: active -> inactive
app:  inactive -> background
view: inactive -> background

And coming back:

app:  background -> inactive
view: background -> inactive
app:  inactive -> active
view: inactive -> active

Always through inactive, in both directions, and the app is told before the view each time.

The line to save on is inactive -> background. Apple's documentation is blunt about what follows: "When an app enters the background phase, expect the app to terminate soon after." There is no later moment you can count on. A suspended app that the system removes from memory is not told anything, and SwiftUI has no equivalent of applicationWillTerminate.

Do not save on active -> inactive instead. That fires for Control Center, the app switcher and every system alert, so you would be saving constantly, and for the wrong reason.

Where this comes from: ScenePhase — Apple, ScenePhase: the app-level value shows background when all scenes are in the background; "you can use that opportunity to free any resources".

No, and the difference is documented. Read inside a view, scenePhase is the phase of the scene that contains that view. Read in the App, it is a summary of all scenes: Apple says it is active "if any scene is active" and inactive "when no scenes are active".

So with two windows, each view's value follows its own window, while the app's value stays active as long as either is. It reaches background only when every window has.

That tells you where each kind of work belongs. Work that concerns one window — pausing its video, stopping its timer — reads the phase in that window's views. Work that concerns the whole app — saving the store — reads it in the App. On an iPhone, with its one window, the two always agree, which is why code that confuses them survives until someone opens a second window on an iPad.

Where this comes from: ScenePhase · WindowGroup — Apple, ScenePhase: "How you interpret the value depends on where it’s read from."

import SwiftUI

@main
struct TripsApp: App {
    @Environment(\.scenePhase) private var scenePhase

    var body: some Scene {
        WindowGroup {
            Text("Trips")
        }
        .onChange(of: scenePhase) { old, new in
            print("\(old) -> \(new)")
        }
    }
}

Control Center does not send an app to the background. With it pulled down over the app, the running app printed only this:

active -> inactive

And when it was swiped away:

inactive -> active

The app was still on the screen, behind the panel, and still running. It was simply not receiving touches. That is what inactive means, and it is the phase the game should have paused on.

The rule: anything that needs the user's attention stops when the phase is no longer active. Saving, and giving up resources, wait for background.

Where this comes from: ScenePhase — Apple describes inactive as a scene that is in the foreground but "should pause its work".

It does not compile. Xcode reports

'main' attribute cannot be used in a module that contains top-level code

'main' attribute cannot be used in a module that contains top-level code Swift has two ways to say where a program starts, and a module may use only one. Code written at the top level of a file named main.swift is the old way: the program starts at its first line. @main on a type is the new way: the program starts by calling that type's static main().

The proposal that introduced @main spells out the corner your colleague hit: "A main.swift file is always considered to be an entry point, even if it has no top-level code." So even an empty file with that name is enough to break the build.

Rename the file, and put the line where code that must run first goes in a SwiftUI app: the init() of the App struct.

Where this comes from: SE-0281: @main: Type-Based Program Entry Points · Hacking with Swift interview question: What does the @main attribute do? — SE-0281, “@main: Type-Based Program Entry Points” (Swift 5.3).

The console shows

starting Trips

It compiles, and it ran: the console shows which branch was taken. @main asks for one thing only — a type with a static method called main(). Hacking with Swift's interview answer puts it this way: with @main you "need to implement a main() method to handle setting up your program, but if you're using SwiftUI the App protocol provides that for you".

Because App gives every conforming type a main(), you can call it yourself, and that makes this pattern possible. Unit tests for an app run inside the app, so by default every test run starts the whole thing: the real store, the real network calls, the real first screen. A launcher like this one starts a bare stand-in app when it sees that tests are loaded, and the tests run faster and touch nothing.

If the type has no main(), the compiler tells you exactly what it wants: a static function of type () -> Void, or the throwing or async forms of it.

Where this comes from: Hacking with Swift interview question: What does the @main attribute do? · SE-0281: @main: Type-Based Program Entry Points · App — Apple, App: "The protocol provides a default implementation of the main() method that the system calls to launch your app."

It compiles, with a warning

'onChange(of:perform:)' was deprecated in iOS 17.0: Use `onChange` with a two or zero parameter action closure instead.

It compiles, with a warning: 'onChange(of:perform:)' was deprecated in iOS 17.0: Use onChange with a two or zero parameter action closure instead.

The first onChange passed its closure one value, the new one. That form has been deprecated since iOS 17. The replacements take either two parameters, the old value and the new, or none at all:

import SwiftUI

struct ContentView: View {
    @Environment(\.scenePhase) private var scenePhase

    var body: some View {
        Text("Trips")
            .onChange(of: scenePhase) { old, new in
                if new == .background {
                    print("save")
                }
            }
    }
}

The difference is more than the parameter count, which is why Apple did not simply add a parameter. The old closure ran before the view was updated, so reading the property inside it gave the old value while the parameter held the new one. The new forms run after the update: inside the closure, the property and new agree. Code that relied on the old timing has to be read again when you convert it. And onChange(of:initial:) with initial: true also runs once when the view first appears, which the old form could not do.

Where this comes from: onChange(of:initial:_:) — The compiler's own deprecation message, and Apple's reference for onChange(of:initial:_:).

Two selections, one store. A WindowGroup is a template: each window the user opens is a fresh copy of the view hierarchy inside its braces. Apple: "Every window in the group maintains independent state. For example, the system allocates new storage for any State or StateObject variables instantiated by the scene's view hierarchy for each window that it creates."

The App struct is outside that template. There is one of it, so there is one store, and both windows are handed the same object. Add a trip in one window and it appears in the other; select a trip in one and the other does not move. That is nearly always the behavior you want, and it falls out of putting each piece of state at the right level.

One more fact for the interview. An iPad app only offers a second window if it says it supports them: the Info.plist key is UIApplicationSupportsMultipleScenes, inside UIApplicationSceneManifest. A new Xcode project sets it for you.

Where this comes from: WindowGroup · Scene — Apple, WindowGroup.

The console shows

1. the App struct is created
2. the delegate hears that launching has finished
   UIApplication's delegate is SwiftUI.AppDelegate
3. the first view appears

Most of it goes in the init() of the App struct, which runs first of all — the console above shows the order. Work that belongs to a model goes in that model, created by the App as @State.

The delegate has not gone; it has been hidden. The running app says that UIApplication's delegate is a class of SwiftUI's own. When you need to receive something that only a delegate is sent — the push-notification token, a background URL session's events, a callback some SDK insists on — you write a delegate class and attach it with @UIApplicationDelegateAdaptor. SwiftUI creates it and forwards to it.

Three rules come with the adaptor, all from Apple's documentation. Declare it only in the App, and only once: a second one is "a runtime error". Do not create the delegate yourself. And prefer not to need it: "Manage an app's life cycle events without using an app delegate whenever possible. For example, prefer to handle changes in ScenePhase instead of relying on delegate callbacks."

Where this comes from: UIApplicationDelegateAdaptor · App — Apple, UIApplicationDelegateAdaptor.