Happy Beam
At a glance
| Item | Summary |
|---|---|
| Purpose | Leverage a Full Space to create a fun game using ARKit. |
| App architecture | A Swift sample with the source-visible chain HappyBeamApp → GameModel → Player → SwiftUI / RealityKit APIs. |
| Main patterns | Publisher-backed observable state |
| Project style | 19 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
| Execution model | Source-visible boundaries: @MainActor, Task closure isolated to MainActor, Task, await suspension point, Sendable or @Sendable; none alone proves a background thread. |
| State/event model | Source-visible mechanisms: @Observable, ObservableObject, @Published. |
| Key frameworks/packages | SwiftUI, RealityKit, GroupActivities, AVKit, Combine; these are source dependencies, not architecture labels. |
Project structure
Source bundle/
├── HappyBeam/
│ ├── HappyBeamApp.swift
│ ├── GameModel.swift
│ ├── Gameplay/
│ │ ├── HeartGestureModel.swift
│ │ ├── Multiplayer.swift
│ │ ├── Clouds.swift
│ │ └── Players.swift
│ ├── HappyBeamSpace.swift
│ ├── Views/
│ │ ├── HappyBeam.swift
│ │ ├── Lobby.swift
│ │ └── MultiPlay.swift
│ └── GlobalEntities.swift
└── Packages/
└── HappyBeamAssets/
└── Sources/
└── HappyBeamAssets/
└── HappyBeamAssets.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 5 project/configuration file(s) and 26 source declaration(s).
Overall architecture
flowchart LR
N1["HappyBeamApp"]
N2["GameModel"]
N3["Player"]
N4["SwiftUI / RealityKit APIs"]
N1 --> N2
N2 --> N3
N3 --> N4
Reference code
HappyBeam/HappyBeamApp.swift:12 — architecture anchor
@main
struct HappyBeamApp: App {
@State private var gameModel = GameModel()
@State private var immersionState: ImmersionStyle = .mixed
var body: some SwiftUI.Scene {
WindowGroup("HappyBeam", id: "happyBeamApp") {
HappyBeam()
.environment(gameModel)
.onAppear {
guard let windowScene = UIApplication.shared.connectedScenes.first as? UIWindowScene else {
return
}
windowScene.requestGeometryUpdate(.Vision(resizingRestrictions: UIWindowScene.ResizingRestrictions.none))
}
}
.windowStyle(.plain)
ImmersiveSpace(id: "happyBeam") {
HappyBeamSpace(gestureModel: HeartGestureModelContainer.heartGestureModel)
.environment(gameModel)
}
.immersionStyle(selection: $immersionState, in: .mixed)
}
}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 visionOS.
Ownership and state
classDiagram
HappyBeamApp *-- GameModel : gameModel
HappyBeamApp *-- ImmersionStyle : immersionState
HappyBeamApp *-- HeartGestureModel : heartGestureModel
GameModel o-- Victoryplayer : victoryPlayer
Ownership evidence
HappyBeam/HappyBeamApp.swift:14 — stored dependency or nearest verified ownership anchor
@main
struct HappyBeamApp: App {
@State private var gameModel = GameModel()
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
HappyBeamApp |
GameModel (gameModel) |
owns wrapper-managed state | Owning lexical scope |
HappyBeamApp |
ImmersionStyle (immersionState) |
owns wrapper-managed state | Owning lexical scope |
HappyBeamApp |
HeartGestureModel (heartGestureModel) |
creates and retains | Owning type writes; wider scope can read |
GameModel |
Victoryplayer (victoryPlayer) |
stores or receives | 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.
Concurrency, scheduling, and thread safety
Evidence limit: actor isolation, async/await, or Task creation does not by itself prove background-thread execution; Sendable conformance alone does not prove thread-safe mutation.
| Concern | Source mechanism | Verified placement or handoff | Evidence |
|---|---|---|---|
| Main isolation | @MainActor |
The cited annotation marks its attached declaration or closure as main-actor isolated. | HappyBeam/GameModel.swift:169 |
| Main isolation | Task closure isolated to MainActor |
The cited operation explicitly enters a main-actor-isolated region. | HappyBeam/GameModel.swift:169 |
| Task creation | Task |
The source creates an unstructured task; surrounding context determines inherited actor isolation. | HappyBeam/GameModel.swift:169 |
| Suspension boundary | await suspension point |
The source declares or crosses an asynchronous boundary; it does not by itself establish background execution. | HappyBeam/GameModel.swift:171 |
| Transfer contract | Sendable or @Sendable |
The source declares a sendability boundary; this alone does not synchronize mutable state. | HappyBeam/Gameplay/HeartGestureModel.swift:13 |
@MainActor/MainActor.run, DispatchQueue.main, and RunLoop.main are reported as distinct isolation, queue, and event-loop mechanisms. A plain Task is kept separate from Task.detached; neither is labeled as a background thread.
Reference code
HappyBeam/GameModel.swift:169 — representative execution boundary
Task { @MainActor in
// ...
named: BundleAssets.heartBlasterEntity,
fromSceneNamed: BundleAssets.heartBlasterScene
// ...
}State propagation, frameworks, and dependencies
Evidence limit: an import proves a source-level compilation dependency at the cited line; it does not prove runtime use, architectural adoption, or whether a Swift package is a direct application dependency.
| Category | Mechanism or module | Verified role | Evidence |
|---|---|---|---|
| State propagation | @Observable |
Observation macro publishes source-visible changes. | HappyBeam/GameModel.swift:13 |
| State propagation | ObservableObject |
ObservableObject supplies an observation contract. | HappyBeam/Gameplay/HeartGestureModel.swift:13 |
| State propagation | @Published |
A published property can emit owner-controlled changes. | HappyBeam/Gameplay/HeartGestureModel.swift:16 |
| Source import | SwiftUI |
The cited file imports this module; runtime use and architectural role are not inferred. | HappyBeam/Extensions.swift:8 |
| Source import | RealityKit |
The cited file imports this module; runtime use and architectural role are not inferred. | HappyBeam/Extensions.swift:9 |
| Source import | GroupActivities |
The cited file imports this module; runtime use and architectural role are not inferred. | HappyBeam/Gameplay/Multiplayer.swift:9 |
| Source import | AVKit |
The cited file imports this module; runtime use and architectural role are not inferred. | HappyBeam/GameModel.swift:8 |
| Source import | Combine |
The cited file imports this module; runtime use and architectural role are not inferred. | HappyBeam/HappyBeamSpace.swift:10 |
receive(on:) describes downstream delivery scheduling, while subscribe(on:) describes upstream subscription/request/cancel scheduling. An import Combine alone establishes neither behavior nor a Store, reducer, Redux, or other application architecture.
Class and protocol design
HappyBeam/HappyBeamApp.swift:13 — representative type boundary
@main
struct HappyBeamApp: App {
@State private var gameModel = GameModel()
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
HappyBeamApp |
Application entry and top-level composition | App |
GameModel |
Feature data or observable state | Concrete collaborators/imported frameworks |
HeartGestureModel |
Feature data or observable state | ObservableObject, @unchecked Sendable |
Player |
Owns media or timeline playback | Concrete collaborators/imported frameworks |
HeartGestureModelContainer |
Defines a closed set of feature states or choices | Concrete collaborators/imported frameworks |
InputKind |
Defines a closed set of feature states or choices | Concrete collaborators/imported frameworks |
HandsUpdates |
Represents a feature value or composable behavior | Concrete collaborators/imported frameworks |
HeartProjection |
Represents a feature value or composable behavior | GroupActivity |
BeamMessage |
Represents a feature value or composable behavior | Codable |
ScoreMessage |
Represents a feature value or composable behavior | Codable |
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 |
|---|---|---|---|
gameModel (HappyBeam/HappyBeamApp.swift:14) |
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. |
immersionState (HappyBeam/HappyBeamApp.swift:15) |
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. |
heartGestureModel (HappyBeam/HappyBeamApp.swift:41) |
private(set) |
Read access follows the declaration; writes remain in the private scope. | Inference: allow observation while reserving invariant-changing writes for the owner. |
emittingBeam (HappyBeam/HappyBeamSpace.swift:21) |
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
HappyBeam/HappyBeamApp.swift:14 — representative boundary
@main
struct HappyBeamApp: App {
@State private var gameModel = GameModel()
// ...
}Swift 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 | HappyBeamApp |
The source’s App suffix makes this role explicit. |
| Feature data or observable state | GameModel, HeartGestureModel |
The source’s Model suffix makes this role explicit. |
| Owns media or timeline playback | Player |
The source’s Player suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| Publisher-backed observable state | HappyBeam/Gameplay/HeartGestureModel.swift:16 |
Published properties notify observers while mutation remains with the state object. |
Main application flow
sequenceDiagram
participant GameModel
participant MainActor
participant Entity
participant AudioFileResource
GameModel->>MainActor: Run UI-isolated work
GameModel->>GameModel: loadFromRealityComposerPro()
GameModel->>Entity: Entity()
GameModel->>GameModel: loadFromRealityComposerPro()
GameModel->>GameModel: loadFromRealityComposerPro()
GameModel->>Entity: Entity()
GameModel->>AudioFileResource: AudioFileResource()
Reference code
HappyBeam/GameModel.swift:194 — init()
@Observable
class GameModel {
// ...
turret = await loadFromRealityComposerPro(named: BundleAssets.heartTurretEntity, fromSceneNamed: BundleAssets.heartTurretScene)
// ...
}Naming conventions
- Types: App: HappyBeamApp; Model: GameModel, HeartGestureModel; Player: Player.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
clear,reset,generateCloudMovementAnimations,start,publishHandTrackingUpdates,monitorSessionEvents,computeTransformOfUserPerformedHeartGesture,startSession. - Files:
HappyBeam/HappyBeamApp.swift,HappyBeam/GameModel.swift,HappyBeam/Gameplay/HeartGestureModel.swift,HappyBeam/HappyBeamSpace.swift,HappyBeam/Views/HappyBeam.swift,HappyBeam/Views/Lobby.swift.
Architecture takeaways
HappyBeamAppis the main source-visible entry or composition anchor for this sample.- Framework work reaches SwiftUI, RealityKit, GroupActivities, AVKit 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 |
|---|---|
HappyBeam/HappyBeamApp.swift |
Cited implementation, HappyBeamApp, HeartGestureModelContainer |
HappyBeam/HappyBeamSpace.swift |
Cited implementation, Combine, HappyBeamSpace, BeamType |
HappyBeam/Gameplay/HeartGestureModel.swift |
Cited implementation, Sendable or @Sendable, ObservableObject, @Published, HeartGestureModel, HandsUpdates |
HappyBeam/GameModel.swift |
@MainActor, Task closure isolated to MainActor, Task, await suspension point, @Observable, AVKit, GameModel, InputKind |
HappyBeam/Extensions.swift |
SwiftUI, RealityKit, Feature implementation |
HappyBeam/Gameplay/Multiplayer.swift |
GroupActivities, HeartProjection, BeamMessage, ScoreMessage, ReadyStateMessage, ProjectionSessionInfo |
HappyBeam/Gameplay/Clouds.swift |
Cloud, CloudAnimations, CloudSpawnParameters |
HappyBeam/Views/HappyBeam.swift |
HappyBeam, GameScreen |
Packages/HappyBeamAssets/Sources/HappyBeamAssets/HappyBeamAssets.swift |
Feature implementation |
HappyBeam/Gameplay/Players.swift |
Player |
HappyBeam/GlobalEntities.swift |
BundleAssets |
HappyBeam/Views/Lobby.swift |
Lobby |
HappyBeam/Views/MultiPlay.swift |
MultiPlay |
HappyBeam/Views/MultiScore.swift |
MultiScore |
HappyBeam/Views/SoloPlay.swift |
SoloPlay |
HappyBeam/Views/SoloScore.swift |
SoloScore |