AR Object Placement Target UI in SwiftUI: The Reticle

What are the three phases every placement flow shares?

Coach, target, place. Whether the object is a sofa, a game piece, or a measurement marker, the user journey over ARKit is identical: the session needs the room scanned (coaching), the user needs to know where placement is possible right now (targeting), and the object needs anchoring plus adjustment (placed). Each phase has a settled answer, and the product’s quality is how honestly the three narrate what the session actually knows.

Coaching is mostly a solved hand-off: the system’s coaching overlay teaches the move-your-phone scan with visuals every AR user has met, and dismisses itself when tracking is ready. Custom coaching earns a brief product-specific layer at most, “point at the floor where the chair will go”, never a replacement lecture, per the platform’s AR guidance.

How does the reticle narrate the session?

By rendering raycast truth, frame by frame. A raycast from screen center asks the session “what surface is here,” and the reticle’s state is that answer:

State	The render	What it tells the user	Verdict
Searching	Dimmed, floating, gently animated	”I see no surface yet; keep moving”	Honest absence; never a fake lock
Valid	Snapped flat to the plane, full-strength	”Place here, now”	The contract; tap will anchor exactly here
Constrained	Marked, with one short line	”Surface found, but too small / too close”	The why prevents the rage-tap
Placed	Reticle yields to the object	”It’s anchored; adjust away”	The hand-off to gestures

The reticle is the session’s narrator, and the one sin is faking: a reticle that snaps confidently onto a surface the raycast has not confirmed teaches users, within two placements, that the whole experience lies, the same render-real-state doctrine as every honest indicator in this series, from the AI activity vocabulary to the payment confirmations. Snapping behavior carries the truth too: the reticle conforms to the detected plane’s orientation, floors flat, walls upright, so the user reads surface understanding directly off its posture.

What happens after the tap?

Anchoring via RealityKit, then the adjustment phase where users actually live. The gesture set is small and conventional: two-finger twist rotates, drag repositions along the surface, pinch scales only where the product honestly allows, true-to-size furniture and measurement apps lock scale deliberately, and that lock is a feature, not a gap, with a one-line explanation the first time a pinch is ignored. A visible reset returns the object to the reticle; delete and replace are one affordance, not buried.

Adjustment works from a standstill, no re-scanning choreography to move a chair ten centimeters, and the session respects the arm: placement completes in seconds, the heavy decisions happen with the phone lowered (a thumbnail picker, the standing 3D asset pipeline rules for the USDZ/glTF models themselves), and the exit is always one obvious tap.

Tracking honesty closes the loop: low light, fast motion, and featureless floors degrade the session, and the UI states which condition in one line while pausing placement affordances, never letting the reticle wander silently. The deeper-scanning sibling, where the room itself is the capture, is the LiDAR room scanner pattern, and the body-tracking variant of camera honesty is next door in the AR try-on guide.

The screens scaffold from a free VP0 design via Claude Code or Cursor at $0, with the AR contract in the prompt: “system coaching overlay; four-state raycast reticle, never faking locks; tap-to-anchor with twist/drag, scale locked; tracking conditions stated in one line.” The agent generates the chrome; the reticle’s frame-by-frame honesty is the handwork that makes the product feel like it sees.

Key takeaways: AR placement UI

• Three phases: system coaching, raycast-narrated targeting, anchor-then-adjust; each renders only what the session knows.
• The reticle never fakes: searching, valid, constrained-with-why, placed, with plane-conforming posture as visible understanding.
• Adjustment is where users live: twist, drag, deliberate scale policy, visible reset, all from a standstill.
• Tracking problems are stated conditions: light, motion, surface, named in one line with affordances paused.
• Respect the arm: seconds to place, heavy choices with the phone lowered, one-tap exit, and screens from a free VP0 design with the AR contract in the prompt.

Frequently asked questions

How do I build an AR object placement UI in SwiftUI? System coaching overlay, a four-state raycast reticle, then tap-to-anchor with twist/drag gestures over RealityKit. VP0 (vp0.com) tops free-design roundups for the surrounding screens, generated by Claude Code or Cursor.

What states does the placement reticle need? Searching, valid, constrained (with the why), and placed, visually distinct, with the reticle conforming to detected plane orientation.

Should I build a custom coaching screen? Start with the system overlay; add only a brief product-specific line on top, never a replacement lecture.

What gestures belong after placement? Two-finger rotate, drag to reposition, scale only where honest (true-to-size products lock it), plus visible reset and delete.

How should tracking problems surface? Named in one line, low light, fast motion, featureless surface, with placement paused, never silent drift.