Tracking accessories in volumetric windows
At a glance
| Item | Summary |
|---|---|
| Purpose | Translate the position and velocity of tracked handheld accessories to throw virtual balls at a stack of cans. |
| App architecture | A Swift sample with the source-visible chain TrackingAccessoriesApp → AccessoryTrackingView → AccessoryTrackingModel → ThrowSpeedTracker → ARKit APIs. |
| Main patterns | View-controller organization, Actor-isolated state |
| Project style | 13 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
└── TrackingAccessories/
├── TrackingAccessoriesApp.swift
├── Models/
│ ├── SpatialController.swift
│ ├── AccessoryTrackingModel.swift
│ └── ThrowSpeedTracker.swift
├── Views/
│ ├── AccessoryTrackingView.swift
│ ├── AppStateView.swift
│ └── GameStateView.swift
└── Entities/
├── Arrow3D.swift
├── Ball.swift
├── Can.swift
├── CanStack.swift
└── Crate.swift
Structure observations
- Architecturally prominent files are ranked from entry points and role-named declarations; resource-only paths are omitted.
- Primary languages: Swift.
- The verified tree contains 4 project/configuration file(s) and 18 source declaration(s).
Overall architecture
flowchart LR
N1["TrackingAccessoriesApp"]
N2["AccessoryTrackingView"]
N3["AccessoryTrackingModel"]
N4["ThrowSpeedTracker"]
N5["ARKit APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
N4 --> N5
Reference code
TrackingAccessories/TrackingAccessoriesApp.swift:12 — architecture anchor
@main
struct TrackingAccessoriesApp: App {
var body: some SwiftUI.Scene {
WindowGroup {
AccessoryTrackingView()
}
.windowStyle(.volumetric)
}
}Interpretation
The arrows summarize the source-visible entry, role-named types or folders, and framework direction; when nodes come from structural folders, the sequence is a high-level interpretation rather than proof that every adjacent node calls the next. Ownership is claimed only where the next section cites a stored property or assignment. The diagram is intentionally limited to the dominant path into ARKit.
Ownership and state
classDiagram
SpatialController o-- AccessoryAnchor : anchor
SpatialController *-- Throw : pendingThrow
SpatialController o-- Throw : triggeredThrow
SpatialController *-- Shake : pendingShake
Ownership evidence
TrackingAccessories/Models/SpatialController.swift:13 — stored dependency or nearest verified ownership anchor
var anchor: AccessoryAnchor? = nil
/// Returns `true` if the controller is connected and you're tracking both the position and the orientation.
var isTracked: Bool {
anchor?.trackingState == .positionOrientationTracked ? true : false
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
SpatialController |
AccessoryAnchor (anchor) |
stores or receives | App/module collaborators |
SpatialController |
Throw (pendingThrow) |
creates and retains | App/module collaborators |
SpatialController |
Throw (triggeredThrow) |
stores or receives | App/module collaborators |
SpatialController |
Shake (pendingShake) |
creates and retains | App/module collaborators |
Composition arrows indicate a source-visible construction expression or locally owned value state; aggregation means the owner stores or receives a dependency without proving exclusive lifetime ownership.
Class and protocol design
TrackingAccessories/TrackingAccessoriesApp.swift:13 — representative type boundary
struct TrackingAccessoriesApp: App {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
TrackingAccessoriesApp |
Application entry and top-level composition | App |
SpatialController |
View lifecycle, callbacks, and feature coordination | Concrete collaborators/imported frameworks |
AccessoryTrackingModel |
Feature data or observable state | Concrete collaborators/imported frameworks |
ThrowSpeedTracker |
Owns tracking state and updates | Concrete collaborators/imported frameworks |
AccessoryTrackingView |
User-interface presentation and input forwarding | View |
AppStateView |
User-interface presentation and input forwarding | View |
GameStateView |
User-interface presentation and input forwarding | View |
Throw |
Represents a feature value or composable behavior | Equatable |
Shake |
Represents a feature value or composable behavior | Equatable |
Direction |
Defines a closed set of feature states or choices | Concrete collaborators/imported frameworks |
No local protocol conformance is claimed as protocol-oriented design; external framework conformances are listed only as dependencies.
Access control
| Symbol | Access | Verified effect | Likely rationale |
|---|---|---|---|
verticalSpacing (TrackingAccessories/Entities/CanStack.swift:10) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
horizontalSpacing (TrackingAccessories/Entities/CanStack.swift:11) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
cans (TrackingAccessories/Entities/CanStack.swift:15) |
private(set) |
Read access follows the declaration; writes remain in the private scope. | Inference: allow observation while reserving invariant-changing writes for the owner. |
toppledCans (TrackingAccessories/Models/AccessoryTrackingModel.swift:35) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: keep state mutation or dependency lifetime inside the owning implementation. |
Reference code
TrackingAccessories/Entities/CanStack.swift:10 — representative boundary
private let verticalSpacing: Float = 0.18Swift declarations without a modifier are internal; explicit private, fileprivate, private(set), public, or open entries above are interpreted by language semantics. Objective-C/C samples instead rely on header and implementation boundaries, which are not equivalent to Swift lexical privacy.
Logic ownership and placement
| Logic | Owning type or file | Placement rationale |
|---|---|---|
| Application entry and top-level composition | TrackingAccessoriesApp |
The source’s App suffix makes this role explicit. |
| View lifecycle, callbacks, and feature coordination | SpatialController |
The source’s Controller suffix makes this role explicit. |
| Feature data or observable state | AccessoryTrackingModel |
The source’s Model suffix makes this role explicit. |
| Owns tracking state and updates | ThrowSpeedTracker |
The source’s Tracker suffix makes this role explicit. |
| User-interface presentation and input forwarding | AccessoryTrackingView, AppStateView, GameStateView |
The source’s View suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| View-controller organization | TrackingAccessories/Models/SpatialController.swift:12 |
A controller is the verified coordination boundary; this is MVC-style only where a separate model is present. |
| Actor-isolated state | TrackingAccessories/Entities/Arrow3D.swift:10 |
Actor annotations make the concurrency ownership boundary explicit. |
Naming conventions
- Types: App: TrackingAccessoriesApp; Controller: SpatialController; Model: AccessoryTrackingModel; Tracker: ThrowSpeedTracker; View: AccessoryTrackingView, AppStateView, GameStateView.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
ballThrown,setCanIsToppled,stopTracking,controller,actOnThrow,actOnShake,trackAllConnectedSpatialControllers,process. - Files:
TrackingAccessories/TrackingAccessoriesApp.swift,TrackingAccessories/Models/SpatialController.swift,TrackingAccessories/Models/AccessoryTrackingModel.swift,TrackingAccessories/Models/ThrowSpeedTracker.swift,TrackingAccessories/Views/AccessoryTrackingView.swift,TrackingAccessories/Views/AppStateView.swift.
Architecture takeaways
TrackingAccessoriesAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches RealityKit, ARKit, SwiftUI, GameController through a deliberately small high-level chain; the detailed API graph remains inside the cited implementation files.
- Stored-property evidence identifies lifecycle collaboration; it does not by itself prove exclusive object ownership.
- Access-control conclusions separate verified language visibility from the likely design rationale.
- The source does not justify labeling the design protocol-oriented.
Source map
| Source file | Relevant symbols |
|---|---|
TrackingAccessories/TrackingAccessoriesApp.swift |
TrackingAccessoriesApp |
TrackingAccessories/Models/SpatialController.swift |
SpatialController, Throw, Shake, Direction |
TrackingAccessories/Models/AccessoryTrackingModel.swift |
AccessoryTrackingModel, GameState, State |
TrackingAccessories/Models/ThrowSpeedTracker.swift |
ThrowSpeedTracker |
TrackingAccessories/Views/AccessoryTrackingView.swift |
AccessoryTrackingView, Attachments |
TrackingAccessories/Views/AppStateView.swift |
AppStateView |
TrackingAccessories/Views/GameStateView.swift |
GameStateView |
TrackingAccessories/Entities/Arrow3D.swift |
Arrow3D |
TrackingAccessories/Entities/Ball.swift |
Ball |
TrackingAccessories/Entities/Can.swift |
Can |