Create a 3D model of an interior room by guiding the user through an AR experience
At a glance
| Item | Summary |
|---|---|
| Purpose | Highlight physical structures and display text that guides a user to scan the shape of their physical environment using a framework-provided view. |
| App architecture | A Swift sample with the source-visible chain AppDelegate → OnboardingViewController → RoomPlan APIs. |
| Main patterns | View-controller organization, Delegate or data-source callbacks |
| Project style | 4 scanned source file(s) across Swift, organized around ranked entry, type, and file boundaries. |
Project structure
Source bundle/
├── RoomPlanExampleApp/
│ ├── AppDelegate.swift
│ ├── OnboardingViewController.swift
│ ├── RoomCaptureViewController.swift
│ ├── SceneDelegate.swift
│ ├── Base.lproj/
│ │ ├── LaunchScreen.storyboard
│ │ ├── Main.storyboard
│ │ └── UnsupportedDevice.storyboard
│ └── Info.plist
├── Configuration/
│ └── SampleCode.xcconfig
└── RoomPlanExampleApp.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 7 project/configuration file(s) and 4 source declaration(s).
Overall architecture
flowchart LR
N1["AppDelegate"]
N2["OnboardingViewController"]
N3["RoomPlan APIs"]
N1 --> N2
N2 --> N3
Reference code
RoomPlanExampleApp/AppDelegate.swift:11 — architecture anchor
@main
class AppDelegate: UIResponder, UIApplicationDelegate {
// ...
}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 RoomPlan.
Ownership and state
classDiagram
OnboardingViewController o-- UIView : existingScanView
RoomCaptureViewController o-- UIButton : exportButton
RoomCaptureViewController o-- UIBarButtonItem : doneButton
RoomCaptureViewController o-- UIBarButtonItem : cancelButton
Ownership evidence
RoomPlanExampleApp/OnboardingViewController.swift:11 — stored dependency or nearest verified ownership anchor
class OnboardingViewController: UIViewController {
@IBOutlet var existingScanView: UIView!
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
OnboardingViewController |
UIView (existingScanView) |
stores or receives | App/module collaborators |
RoomCaptureViewController |
UIButton (exportButton) |
stores or receives | App/module collaborators |
RoomCaptureViewController |
UIBarButtonItem (doneButton) |
stores or receives | App/module collaborators |
RoomCaptureViewController |
UIBarButtonItem (cancelButton) |
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.
Class and protocol design
RoomPlanExampleApp/AppDelegate.swift:12 — representative type boundary
class AppDelegate: UIResponder, UIApplicationDelegate {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
AppDelegate |
Receives callback-driven events | UIResponder, UIApplicationDelegate |
OnboardingViewController |
View lifecycle, callbacks, and feature coordination | UIViewController |
RoomCaptureViewController |
View lifecycle, callbacks, and feature coordination | UIViewController, RoomCaptureViewDelegate, RoomCaptureSessionDelegate |
SceneDelegate |
Receives callback-driven events | UIResponder, UIWindowSceneDelegate |
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 |
|---|---|---|---|
isScanning (RoomPlanExampleApp/RoomCaptureViewController.swift:19) |
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. |
roomCaptureView (RoomPlanExampleApp/RoomCaptureViewController.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. |
roomCaptureSessionConfig (RoomPlanExampleApp/RoomCaptureViewController.swift:22) |
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. |
finalResults (RoomPlanExampleApp/RoomCaptureViewController.swift:24) |
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
RoomPlanExampleApp/RoomCaptureViewController.swift:19 — representative boundary
private var isScanning: Bool = false
private var roomCaptureView: RoomCaptureView!
private var roomCaptureSessionConfig: RoomCaptureSession.Configuration = RoomCaptureSession.Configuration()
private var finalResults: CapturedRoom?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 |
|---|---|---|
| View lifecycle, callbacks, and feature coordination | OnboardingViewController, RoomCaptureViewController |
The source’s Controller suffix makes this role explicit. |
| Receives callback-driven events | AppDelegate, SceneDelegate |
The source’s Delegate suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| View-controller organization | RoomPlanExampleApp/OnboardingViewController.swift:10 |
A controller is the verified coordination boundary; this is MVC-style only where a separate model is present. |
| Delegate or data-source callbacks | RoomPlanExampleApp/AppDelegate.swift:12 |
Callback protocols invert event delivery back into the sample’s owner. |
Naming conventions
- Types: Controller: OnboardingViewController, RoomCaptureViewController; Delegate: AppDelegate, SceneDelegate.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
application,startScan,viewDidLoad,setupRoomCaptureView,viewDidAppear,viewWillDisappear,startSession,stopSession. - Files:
RoomPlanExampleApp/AppDelegate.swift,RoomPlanExampleApp/OnboardingViewController.swift,RoomPlanExampleApp/RoomCaptureViewController.swift,RoomPlanExampleApp/SceneDelegate.swift.
Architecture takeaways
AppDelegateis the main source-visible entry or composition anchor for this sample.- Framework work reaches UIKit, RoomPlan 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 |
|---|---|
RoomPlanExampleApp/AppDelegate.swift |
AppDelegate |
RoomPlanExampleApp/OnboardingViewController.swift |
OnboardingViewController |
RoomPlanExampleApp/RoomCaptureViewController.swift |
RoomCaptureViewController |
RoomPlanExampleApp/SceneDelegate.swift |
SceneDelegate |