Associating a window with an immersive space
At a glance
| Item | Summary |
|---|---|
| Purpose | Tightly couple a window with an immersive space for persistent controls. |
| App architecture | SampleApp composes Window + ImmersiveSpace around ContentView; AppModel owns interaction while RealityView manages the entity graph. |
| Main patterns | SwiftUI scene composition, SwiftUI–RealityKit bridge, Explicit immersive-space lifecycle, Observable state owner |
| Project style | Code-light sample with 8 scanned Swift file(s) and 283 Swift line(s); resources and generated assets are excluded from those counts. |
Project structure
Source bundle/
├── SampleApp/SampleApp.swift # SceneID, SampleApp
├── SampleApp/AppModel.swift # AppModel, ImmersiveSpaceState
├── SampleApp/ContentView.swift # ContentView
├── SampleApp/ControlsView.swift # ControlsView
├── SampleApp/ImmersiveView.swift # ImmersiveView
├── Packages/RealityKitContent/Sources/RealityKitContent/RealityKitContent.swift
├── SampleApp/ToggleImmersiveSpaceButton.swift # ToggleImmersiveSpaceButton
├── Packages/RealityKitContent/Package.swift
└── Packages/RealityKitContent/Package.realitycomposerpro/ProjectData/main.json # authored RealityKit content
Structure observations
- The runtime boundary is Window + ImmersiveSpace; 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.
- Authored
.realityor 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___ImmersiveSpace_2["Window + ImmersiveSpace"]
ContentView_3["ContentView"]
AppModel_4["AppModel"]
RealityView_entity_graph_5["RealityView entity graph"]
RealityKit_entity_graph_6["RealityKit entity graph"]
SampleApp_1 --> Window___ImmersiveSpace_2
Window___ImmersiveSpace_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
ContentView o-- AppModel : appModel
Ownership evidence
SampleApp/SampleApp.swift:18 — representative stored state or the nearest verified lifecycle anchor.
@State private var appModel = AppModel()| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
SampleApp |
AppModel as appModel |
creates and retains | Only the declaring scope writes |
ContentView |
AppModel as appModel |
receives a shared/non-owning reference | The upstream owner controls lifetime; this scope may invoke its mutable API |
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
| Type | Responsibility | Depends on or conforms to |
|---|---|---|
SampleApp (SampleApp/SampleApp.swift:17) |
Declares app scenes and top-level dependency lifetime. | App |
ContentView (SampleApp/ContentView.swift:12) |
Presents UI and forwards gestures or lifecycle events. | View |
AppModel (SampleApp/AppModel.swift:12) |
Owns observable feature state and domain transitions. | Concrete framework collaborators |
ControlsView (SampleApp/ControlsView.swift:10) |
Presents UI and forwards gestures or lifecycle events. | View |
ImmersiveView (SampleApp/ImmersiveView.swift:12) |
Presents UI and forwards gestures or lifecycle events. | View |
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
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
@Environment(AppModel.self) private var appModel (SampleApp/ContentView.swift:13) |
private |
Use is restricted to the declaration and same-file extensions permitted by Swift. | Inference: Hide implementation details and lifecycle-sensitive state. |
No reviewed declaration uses fileprivate, private(set), public, open; unmodified Swift declarations are internal.
Reference code
SampleApp/ContentView.swift:13 — representative visibility boundary.
@Environment(AppModel.self) private var appModelLogic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Scene declaration and dependency lifetime | SampleApp |
The App/entry boundary determines window, volume, and immersive-space lifetime. |
| Presentation, attachments, and gestures | ContentView |
SwiftUI view code forwards user intent and RealityView lifecycle events. |
| Shared feature state and commands | AppModel |
A role-named owner prevents sibling views from duplicating transitions. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| SwiftUI scene composition | SampleApp/SampleApp.swift:17 |
Keeps windows, volumes, and immersive-space lifecycle visible at the app boundary. |
| SwiftUI–RealityKit bridge | SampleApp/ImmersiveView.swift:15 |
Builds and updates a RealityKit entity graph from SwiftUI lifecycle closures. |
| Explicit immersive-space lifecycle | SampleApp/SampleApp.swift:33 |
Makes immersive presentation a scene transition rather than hidden global state. |
| Observable state owner | SampleApp/AppModel.swift:12 |
Shares feature state across multiple views without moving framework resources into view values. |
Naming conventions
- Role suffixes are evidence, not decoration: App:
SampleApp; Model:AppModel; View:ContentView,ControlsView,ImmersiveView. - 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, andPackagesfolders describe architectural roles where present.
Architecture takeaways
- Treat
SampleAppas 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.
- Model immersive-space open, transition, and close states explicitly so windows and immersive content cannot drift apart.
- 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
| Source file | Relevant symbols |
|---|---|
SampleApp/SampleApp.swift:10 |
SceneID, SampleApp |
SampleApp/AppModel.swift:12 |
AppModel, ImmersiveSpaceState |
SampleApp/ContentView.swift:12 |
ContentView |
SampleApp/ControlsView.swift:10 |
ControlsView |
SampleApp/ImmersiveView.swift:12 |
ImmersiveView |
Packages/RealityKitContent/Sources/RealityKitContent/RealityKitContent.swift:1 |
Feature implementation |
SampleApp/ToggleImmersiveSpaceButton.swift:10 |
ToggleImmersiveSpaceButton |
Packages/RealityKitContent/Package.swift:1 |
Feature implementation |