BOT-anist

At a glance

Project structure

Source bundle/
├── BOT-anist/BOTanistApp.swift  # BOTanistApp
├── Packages/BOTanistAssets/Sources/BOTanistAssets/Components/PlantComponent.swift  # PlantComponent, PlantTypeKey
├── BOT-anist/Robot/RobotData.swift  # RobotData, RobotMaterial, BodyType
├── BOT-anist/Views/RobotView.swift  # RobotView, ResizableRealityView, StartPlantingButtonView
├── BOT-anist/Views/ContentView.swift  # ContentView
├── BOT-anist/AppState.swift  # AppPhase, AppState
├── BOT-anist/Components/JointPinComponent.swift  # JointPinComponent
├── BOT-anist/Systems/JointPinSystem.swift  # JointPinSystem
└── Packages/BOTanistAssets/Package.realitycomposerpro/ProjectData/main.json  # authored RealityKit content

Structure observations

• The runtime boundary is 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
    BOTanistApp_1["BOTanistApp"]
    WindowGroup___volumetric_window_2["WindowGroup + volumetric window"]
    ContentView_3["ContentView"]
    AppState_4["AppState"]
    RealityView_entity_graph_5["RealityView entity graph"]
    RealityKit_components_and_systems_6["RealityKit components and systems"]
    BOTanistApp_1 --> WindowGroup___volumetric_window_2
    WindowGroup___volumetric_window_2 --> ContentView_3
    ContentView_3 --> AppState_4
    AppState_4 --> RealityView_entity_graph_5
    RealityView_entity_graph_5 --> RealityKit_components_and_systems_6

Reference code

BOT-anist/BOTanistApp.swift:16 — the app or executable entry declares the outer scene lifecycle.

struct BOTanistApp: 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
    BOTanistApp *-- AppState : appState
    ContentView o-- AppState : appState
    BOTanistApp *-- Size3D : initialVolumeSize
    PlantAnimationProvider *-- PlantAnimationProvider : shared

Ownership evidence

BOT-anist/BOTanistApp.swift:20 — representative stored state or the nearest verified lifecycle anchor.

    @State private var appState = AppState()

    /// The initial 3D dimensions of the volumetric window.
    private var initialVolumeSize: Size3D = Size3D(width: 900, height: 500, depth: 900)
    
    /// The initial 2D dimensions of the content view window.
    private var initialWindowSize: CGSize = CGSize(width: 1166, height: 680)

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

Reference code

BOT-anist/BOTanistApp.swift:20 — representative visibility boundary.

@main
struct BOTanistApp: App {
    // ...
    @State private var appState = AppState()
    // ...
}

Logic ownership and placement

Design patterns

Naming conventions

• Role suffixes are evidence, not decoration: App: BOTanistApp; Provider: PlantAnimationProvider; View: ContentView, ExplorationView, FaceSelectorView, LightColorSelectView, MaterialColorSelectView.
• ECS names pair data and behavior: components JointPinComponent, PlantComponent; systems JointPinSystem.
• Protocols: no app-defined protocol in the reviewed source.
• Commands use verb-led methods: partForMaterialName, color, randomColor, face, hash, handleDrag, adjustRobotToFillCenterOfView.
• Files generally match their primary type; Views, Models, Managers, Providers, Components, Systems, and Packages folders describe architectural roles where present.

Architecture takeaways

• Treat BOTanistApp 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.
• Use RealityKit components for per-entity data and systems for repeated simulation instead of a monolithic view model.

Source map

• Official Apple documentation