Handling the window life cycle with multiple scenes

At a glance

Project structure

Source bundle/
├── SampleApp/SampleApp.swift  # SceneID, SampleApp
├── SampleApp/AppModel.swift  # AppModel, WindowState
├── SampleApp/ScenePhaseMonitor.swift  # SceneStateWindowViewModifier, SceneStateWindowGroupViewModifier
├── SampleApp/SphereModel.swift  # SphereModel, ColorOption
├── SampleApp/ContentView.swift  # ContentView
├── SampleApp/ControlsView.swift  # ControlsView
├── SampleApp/SphereVolume.swift  # SphereVolume
├── SampleApp/WindowStateButton.swift  # WindowStateButton, OpenButton, CloseButton
└── Packages/RealityKitContent/Package.realitycomposerpro/ProjectData/main.json  # authored RealityKit content

Structure observations

• The runtime boundary is Window + WindowGroup + volumetric window; the pruned tree lists only files that explain lifecycle, state, or framework integration.
• App code is split into role-named views, models, managers, providers, components, or systems.
• Authored .reality or Reality Composer Pro content is a real implementation boundary; Swift loads or drives it rather than reproducing its entity graph.

Overall architecture

flowchart LR
    SampleApp_1["SampleApp"]
    Window___WindowGroup___volumetric_window_2["Window + WindowGroup + volumetric window"]
    ContentView_3["ContentView"]
    AppModel_4["AppModel"]
    RealityView_entity_graph_5["RealityView entity graph"]
    RealityKit_entity_graph_6["RealityKit entity graph"]
    SampleApp_1 --> Window___WindowGroup___volumetric_window_2
    Window___WindowGroup___volumetric_window_2 --> ContentView_3
    ContentView_3 --> AppModel_4
    AppModel_4 --> RealityView_entity_graph_5
    RealityView_entity_graph_5 --> RealityKit_entity_graph_6

Reference code

SampleApp/SampleApp.swift:17 — the app or executable entry declares the outer scene lifecycle.

struct SampleApp: App {
    // ...
}

The diagram is a responsibility flow, not a claim that every adjacent node directly calls the next. It keeps scene ownership, shared state, RealityKit content, and framework-provider work at separate levels.

Ownership and state

classDiagram
    SampleApp *-- AppModel : appModel
    WindowState --> WindowState : sphereLauncherWindowState
    WindowStateButton --> SphereModel : sphere
    OpenButton --> SphereModel : sphere

Ownership evidence

SampleApp/SampleApp.swift:18 — representative stored state or the nearest verified lifecycle anchor.

    @State private var appModel = AppModel()

Ownership here is deliberately narrow: @Environment and weak references are shared links, initialized @State or stored services are lifecycle ownership, and a RealityView content closure owns additions to its entity graph without making the SwiftUI view a reference-type owner.

Class and protocol design

The source defines no local substitution protocol in the reviewed boundary. Its protocol use is framework-facing (App, View, RealityKit/ARKit protocols, or platform adapters), so this document does not label the whole app protocol-oriented.

Access control

No reviewed declaration uses fileprivate, private(set), open; unmodified Swift declarations are internal.

Reference code

SampleApp/ControlsView.swift:11 — representative visibility boundary.

    @Environment(AppModel.self) private var appModel
    @Environment(\.openWindow) private var openWindow
    @Environment(\.dismissWindow) private var dismissWindow

    @SceneStorage("enlarge") private var enlarge: Bool = false

Logic ownership and placement

Design patterns

Naming conventions

• Role suffixes are evidence, not decoration: App: SampleApp; Model: AppModel, SphereModel; View: ContentView, ControlsView.
• Protocols: no app-defined protocol in the reviewed source.
• Commands use verb-led methods: updateWindowState, unregisterWindow, windowState, monitorScenePhase, body.
• Files generally match their primary type; Views, Models, Managers, Providers, Components, Systems, and Packages folders describe architectural roles where present.

Architecture takeaways

• Treat SampleApp as the owner of scene declarations, not as the owner of every RealityKit entity created later.
• Keep view-local interaction in SwiftUI, but move provider sessions, playback resources, shared game state, or transport state into a stable owner when their lifetime exceeds one render pass.

Source map

• Official Apple documentation