Detecting Images in an AR Experience
At a glance
| Item | Summary |
|---|---|
| Purpose | React to known 2D images in the user’s environment, and use their positions to place AR content. |
| App architecture | A Swift sample with the source-visible chain AppDelegate → StatusViewController → ARKit 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/
├── ARKitImageDetection/
│ ├── AppDelegate.swift
│ ├── Additional View Controllers/
│ │ └── StatusViewController.swift
│ ├── ViewController.swift
│ ├── ViewController+ARSessionDelegate.swift
│ ├── Base.lproj/
│ │ └── Main.storyboard
│ └── Resources/
│ ├── Info.plist
│ └── LaunchScreen.storyboard
├── ARKitImageDetection.xcodeproj/
│ ├── .xcodesamplecode.plist
│ └── project.pbxproj
└── Configuration/
└── SampleCode.xcconfig
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 6 project/configuration file(s) and 4 source declaration(s).
Overall architecture
flowchart LR
N1["AppDelegate"]
N2["StatusViewController"]
N3["ARKit APIs"]
N1 --> N2
N2 --> N3
Reference code
ARKitImageDetection/AppDelegate.swift:11 — architecture anchor
@UIApplicationMain
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 ARKit.
Ownership and state
classDiagram
AppDelegate o-- UIWindow : window
StatusViewController *-- Array : all
StatusViewController o-- Callback : restartExperienceHandler
StatusViewController o-- TimeInterval : displayDuration
Ownership evidence
ARKitImageDetection/AppDelegate.swift:13 — stored dependency or nearest verified ownership anchor
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
var window: UIWindow?
// ...
}| Owner | Object or state | Relationship | Mutation authority |
|---|---|---|---|
AppDelegate |
UIWindow (window) |
stores or receives | App/module collaborators |
StatusViewController |
Array (all) |
owns value state | App/module collaborators |
StatusViewController |
Callback (restartExperienceHandler) |
stores a callback | App/module collaborators |
StatusViewController |
TimeInterval (displayDuration) |
stores or receives | Initialized by the owner; the binding is immutable |
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
ARKitImageDetection/AppDelegate.swift:12 — representative type boundary
class AppDelegate: UIResponder, UIApplicationDelegate {
// ...
}| Type | Responsibility | Depends on or conforms to |
|---|---|---|
AppDelegate |
Receives callback-driven events | UIResponder, UIApplicationDelegate |
StatusViewController |
View lifecycle, callbacks, and feature coordination | UIViewController |
ViewController |
View lifecycle, callbacks, and feature coordination | UIViewController, ARSCNViewDelegate |
MessageType |
Defines a closed set of feature states or choices | Concrete collaborators/imported frameworks |
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 |
|---|---|---|---|
displayDuration (ARKitImageDetection/Additional View Controllers/StatusViewController.swift:42) |
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. |
messageHideTimer (ARKitImageDetection/Additional View Controllers/StatusViewController.swift:45) |
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. |
timers (ARKitImageDetection/Additional View Controllers/StatusViewController.swift:47) |
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. |
restartExperience (ARKitImageDetection/Additional View Controllers/StatusViewController.swift:114) |
private |
Use is restricted to the lexical declaration and same-file extensions allowed by Swift. | Inference: hide an implementation step that is not part of the collaboration surface. |
Reference code
ARKitImageDetection/Additional View Controllers/StatusViewController.swift:42 — representative boundary
private let displayDuration: TimeInterval = 6
// Timer for hiding messages.
private var messageHideTimer: Timer?
private var timers: [MessageType: Timer] = [:]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 | StatusViewController, ViewController |
The source’s Controller suffix makes this role explicit. |
| Receives callback-driven events | AppDelegate |
The source’s Delegate suffix makes this role explicit. |
Design patterns
| Pattern | Source evidence | Purpose or tradeoff |
|---|---|---|
| View-controller organization | ARKitImageDetection/Additional View Controllers/StatusViewController.swift:16 |
A controller is the verified coordination boundary; this is MVC-style only where a separate model is present. |
| Delegate or data-source callbacks | ARKitImageDetection/AppDelegate.swift:12 |
Callback protocols invert event delivery back into the sample’s owner. |
Naming conventions
- Types: Controller: StatusViewController, ViewController; Delegate: AppDelegate.
- Protocols: no local protocol declaration in the scanned source.
- Methods:
application,showMessage,scheduleMessage,cancelScheduledMessage,cancelAllScheduledMessages,showTrackingQualityInfo,escalateFeedback,restartExperience. - Files:
ARKitImageDetection/AppDelegate.swift,ARKitImageDetection/Additional View Controllers/StatusViewController.swift,ARKitImageDetection/ViewController.swift.
Architecture takeaways
AppDelegateis the main source-visible entry or composition anchor for this sample.- Framework work reaches ARKit, UIKit, SceneKit 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 |
|---|---|
ARKitImageDetection/AppDelegate.swift |
AppDelegate |
ARKitImageDetection/Additional View Controllers/StatusViewController.swift |
StatusViewController, MessageType |
ARKitImageDetection/ViewController.swift |
ViewController |
ARKitImageDetection/ViewController+ARSessionDelegate.swift |
Feature implementation |