Simulating physics with collisions in your visionOS app

At a glance

Project structure

Source bundle/
└── PhysicsBodies/
    ├── MainView.swift  # MainView
    ├── SphereAttractionSystem.swift  # SphereAttractionSystem
    ├── PhysicsBodiesApp.swift  # PhysicsBodiesApp
    ├── SphereAttractionComponent.swift  # SphereAttractionComponent
    ├── EntityDragGesture.swift  # EntityDragGesture, GestureStateComponent
    ├── ContainmentCollisionBox.swift  # ContainmentCollisionBox
    └── ForceDragGesture.swift  # ForceDragGesture

Structure observations

• The runtime boundary is WindowGroup + volumetric window; the tree is pruned to lifecycle, state, framework, rendering, and ECS files.
• The source is Swift; role-named types and feature folders separate the major responsibilities.

Overall architecture

flowchart LR
    PhysicsBodiesApp_1["PhysicsBodiesApp"]
    WindowGroup___volumetric_window_2["WindowGroup + volumetric window"]
    MainView_3["MainView"]
    SphereAttractionSystem_4["SphereAttractionSystem"]
    RealityKit_entity_graph_5["RealityKit entity graph"]
    RealityKit_collisions___ECS_6["RealityKit collisions + ECS"]
    PhysicsBodiesApp_1 --> WindowGroup___volumetric_window_2
    WindowGroup___volumetric_window_2 --> MainView_3
    MainView_3 --> SphereAttractionSystem_4
    SphereAttractionSystem_4 --> RealityKit_entity_graph_5
    RealityKit_entity_graph_5 --> RealityKit_collisions___ECS_6

Reference code

PhysicsBodies/PhysicsBodiesApp.swift:11 — executable or app-lifecycle anchor.

struct PhysicsBodiesApp: App {
    var body: some Scene {
        WindowGroup {
            MainView()
        }.windowStyle(.volumetric)
    }
}

The diagram is a responsibility flow, not a claim that every adjacent node directly calls the next. It separates lifecycle, presentation, stable state, framework/session work, and the RealityKit entity graph.

Ownership and state

classDiagram
    MainView *-- ContainmentCollisionBox : containmentCollisionBox
    SphereAttractionSystem --> EntityQuery : entityQuery
    GestureStateComponent --> Closure : closure
    ContainmentCollisionBox --> BoundingBox : lastBoundingBox

Ownership evidence

PhysicsBodies/MainView.swift:13 — representative stored state or nearest verified lifecycle anchor.

struct MainView: View {
    // ...
    @State var containmentCollisionBox = ContainmentCollisionBox()
    // ...
}

Ownership is intentionally narrow: environment, bindings, observed objects, weak links, and delegate callbacks do not prove lifetime ownership. Initialized stored services and wrapper-managed state do; entities added inside a RealityKit content closure belong to that entity graph.

Class and protocol design

The reviewed source defines no local substitution protocol. Its App, View, delegate, renderer, ARKit, and RealityKit conformances are framework-facing contracts, so this document does not label the whole app protocol-oriented.

Access control

No reviewed Swift access example uses fileprivate, private(set), public, open; declarations without a modifier are internal.

Reference code

PhysicsBodies/Entity+CollisionPhysicsBox.swift:12 — representative visibility boundary.

private let defaultMass1Kg = Float(1.0)

Logic ownership and placement

Design patterns

Naming conventions

• Role suffixes are evidence, not decoration: App: PhysicsBodiesApp; System: SphereAttractionSystem; Component: GestureStateComponent, SphereAttractionComponent; View: MainView.
• ECS names pair data and behavior: components GestureStateComponent, SphereAttractionComponent; systems SphereAttractionSystem.
• Protocols: no app-defined protocol in the reviewed source.
• Commands use verb-led methods: addSpheres, update, startPosition.
• Files and folders use primary-type or responsibility names such as Views, Models, Rendering, Components, Systems, Packages, or feature names where those boundaries exist.

Architecture takeaways

• Treat PhysicsBodiesApp as the owner of executable or scene lifecycle, not automatically as the owner of every entity created later.
• Keep view/controller input near presentation, but move sessions, reconstruction, capture, rendering, shared game state, or documents into stable owners when their lifetime exceeds one callback or render pass.
• Use components for per-entity data and systems for repeated simulation instead of centralizing every update in a view model or controller.

Source map

• Official Apple documentation