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 EntryPoint → MainView → SwiftUI / 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
flowchart LR
N1["EntryPoint"]
N2["MainView"]
N3["SwiftUI / RealityKit APIs"]
N1 --> N2
N2 --> N3
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
classDiagram
GlassView *-- Float : roughness
GlassView *-- Float : eta
GlassView *-- Entity : entity
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
EntryPointis 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 |