Sample CodevisionOSReviewed 2026-07-21View on Apple Developer

Implementing adjustable material

At a glance

Item Summary
Purpose Update the adjustable parameters of a 3D model in visionOS.
App architecture A Swift sample with the source-visible chain EntryPointMainViewSwiftUI / RealityKit APIs.
Main patterns No named application pattern supported by the extracted structure
Project style 4 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries.
Execution model Source-visible boundaries: await suspension point; none alone proves a background thread.
State/event model Source-visible mechanisms: SwiftUI state property wrapper.
Key frameworks/packages SwiftUI, RealityKit; these are source dependencies, not architecture labels.

Project structure

Source bundle/
├── Glass/
│   ├── App/
│   │   ├── EntryPoint.swift
│   │   └── Info.plist
│   ├── Views/
│   │   ├── GlassView.swift
│   │   └── MainView.swift
│   └── Extentions/
│       └── Entity.swift
├── Configuration/
│   └── SampleCode.xcconfig
└── Glass.xcodeproj/
    ├── .xcodesamplecode.plist
    └── project.pbxproj

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 3 source declaration(s).

Overall architecture

Reference code

Glass/App/EntryPoint.swift:10 — architecture anchor

@main
struct GlassApp: App {
    var body: some Scene {
        WindowGroup {
            MainView()
        }
    }
}

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

Ownership evidence

Glass/Views/GlassView.swift:14 — stored dependency or nearest verified ownership anchor

struct GlassView: View {
    // ...
    @State var roughness: Float = 0.2
    // ...
}
Owner Object or state Relationship Mutation authority
GlassView Float (roughness) owns wrapper-managed state App/module collaborators
GlassView Float (eta) owns wrapper-managed state App/module collaborators
GlassView Entity (entity) owns wrapper-managed state 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
Suspension boundary await suspension point The source declares or crosses an asynchronous boundary; it does not by itself establish background execution. Glass/Views/GlassView.swift:28

@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

Glass/Views/GlassView.swift:28 — representative execution boundary

struct GlassView: View {
    // ...
                    let entity = try await Entity(named: fileName)
    // ...
}

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 SwiftUI state property wrapper A SwiftUI property wrapper supplies or observes UI state. Glass/Views/GlassView.swift:14
Source import SwiftUI The cited file imports this module; runtime use and architectural role are not inferred. Glass/App/EntryPoint.swift:8
Source import RealityKit The cited file imports this module; runtime use and architectural role are not inferred. Glass/Extentions/Entity.swift:8

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

Glass/App/EntryPoint.swift:11 — representative type boundary

@main
struct GlassApp: App {
    // ...
            MainView()
    // ...
}
Type Responsibility Depends on or conforms to
GlassApp Application entry and top-level composition App
GlassView User-interface presentation and input forwarding View
MainView User-interface presentation and input forwarding View

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
updateMaterials (Glass/Extentions/Entity.swift:13) public The symbol is visible to importing modules. Inference: make the declaration available across a module or target boundary.
MainView (Glass/Views/MainView.swift:8) implicit internal No explicit modifier means the Swift declaration is internal to the module. Inference: app-target collaboration needs no exported library surface.

Reference code

Glass/Extentions/Entity.swift:13 — representative boundary

    public func updateMaterials(_ update: (inout Material) -> Void) {
        // ...
            child.updateMaterials(update)
        // ...
    }

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 GlassApp The source’s App suffix makes this role explicit.
User-interface presentation and input forwarding GlassView, MainView The source’s View suffix makes this role explicit.

Design patterns

Pattern Source evidence Purpose or tradeoff
No named application pattern Glass/App/EntryPoint.swift:10 The verified source directly composes concrete framework types; this document avoids forcing a pattern name.

Naming conventions

  • Types: App: GlassApp; View: GlassView, MainView.
  • Protocols: no local protocol declaration in the scanned source.
  • Methods: updateMaterials.
  • Files: Glass/Views/GlassView.swift, Glass/Views/MainView.swift.

Architecture takeaways

  • EntryPoint is the main source-visible entry or composition anchor for this sample.
  • Framework work reaches SwiftUI, RealityKit 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
Glass/App/EntryPoint.swift Cited implementation, GlassApp, SwiftUI
Glass/Views/GlassView.swift Cited implementation, await suspension point, SwiftUI state property wrapper, GlassView
Glass/Extentions/Entity.swift Cited implementation, RealityKit, Feature implementation
Glass/Views/MainView.swift MainView