Creating SwiftUI windows in visionOS

At a glance

Project structure

Source bundle/
└── Creating New Windows/
    ├── App/
    │   └── EntryPoint.swift  # EntryPoint
    └── Views/
        ├── OpenWindowView.swift  # OpenWindowView, NewWindowID
        ├── MainView.swift  # MainView
        └── NewWindowView.swift  # NewWindowView

Structure observations

• The runtime boundary is WindowGroup; the pruned tree lists only files that explain lifecycle, state, or framework integration.
• App code is compact; any explicit model, provider, or entity owner is still shown below rather than collapsed into view-local state.

Overall architecture

flowchart LR
    EntryPoint_1["EntryPoint"]
    WindowGroup_2["WindowGroup"]
    MainView_3["MainView"]
    SwiftUI_scene_APIs_4["SwiftUI scene APIs"]
    EntryPoint_1 --> WindowGroup_2
    WindowGroup_2 --> MainView_3
    MainView_3 --> SwiftUI_scene_APIs_4

Reference code

Creating New Windows/App/EntryPoint.swift:11 — the app or executable entry declares the outer scene lifecycle.

struct EntryPoint: 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
    OpenWindowView *-- NewWindowID : nextWindowID

Ownership evidence

Creating New Windows/Views/OpenWindowView.swift:14 — representative stored state or the nearest verified lifecycle anchor.

struct OpenWindowView: View {
    // ...
    @State var nextWindowID = NewWindowID(id: 1)
    // ...
}

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), public, open; unmodified Swift declarations are internal.

Reference code

Creating New Windows/Views/OpenWindowView.swift:17 — representative visibility boundary.

struct OpenWindowView: View {
    // ...
    @Environment(\.openWindow) private var openWindow
    // ...
}

Logic ownership and placement

Design patterns

Naming conventions

• Role suffixes are evidence, not decoration: View: MainView, NewWindowView, OpenWindowView.
• Protocols: no app-defined protocol in the reviewed source.
• Commands use verb-led methods: the code-light sample has no separate command layer.
• Files generally match their primary type; Views, Models, Managers, Providers, Components, Systems, and Packages folders describe architectural roles where present.

Architecture takeaways

• Treat EntryPoint 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.
• The compact source does not justify adding repository, coordinator, or protocol layers beyond the model, provider, or view boundary the sample actually declares.

Source map

• Official Apple documentation