The phone could track the room and still miss the table

I could see the tabletop. The app still could not place the virtual workspace on it.

Our September 22 iPhone Air checks exposed a gap between what a person could see and what the AR interaction could use. The first diagnostic session reported normal tracking and a detected horizontal plane, received 16 tap callbacks, and returned zero intersections from its plane-geometry raycasts.

The taps were reaching the app. A plane existed somewhere in the tracked scene. Neither fact meant that the detected plane geometry covered the point being tapped.

Three stages hiding behind one tap

Initial placement depended on a chain of conditions:

tracking available
    → horizontal plane detected
    → tap ray intersects usable plane geometry
    → workspace placement

In that first session, the chain reached plane detection and stopped at the intersection. The code returned silently on a miss. From the person's side, tapping appeared to do nothing.

We added a bounded initial-placement fallback to an already detected horizontal plane and a reason for a rejected tap. That was a specific response to the observed failure, not evidence that every tabletop would now work.

The next phone check had a different problem. Tracking was normal, but no horizontal plane was detected during seven eligible taps. A fallback that requires a detected plane could not help in that state.

Observed state	Useful explanation
Plane detected, tap has no intersection	No usable intersection was returned
No plane detected	Placement has no surface to use yet
Tracking later becomes limited	The session needs to explain the tracking condition too

We made the no-hit/no-plane distinction visible on the camera screen and added a center placement cue that appeared only when a valid surface intersection existed. A later two-tap check still had no detected plane, so it could not demonstrate that cue or the detected-plane fallback working.

The useful alternative was hard to find

There was already another way to change the target: the numeric Goal editor. It did not need camera registration.

I had trouble finding this editor while the app said “Reconnecting.” That message referred to the Mac connection, but it appeared alongside a task the phone could still do locally.

The next change put a short explanation of the example's 0.15 m tool-point target height on the AR screen, together with “Edit target without camera.” The action returned to the ordinary Goal editor.

On the Air, I could see the explanation and action, and I could use that path to change the target height. The 0.15 m value was an example target, not a measurement of the tabletop.

The numeric path gave me a useful edit while surface placement was unresolved. It did not validate AR alignment, place the workspace or run a simulation.

Tracking, plane detection and tap intersection still needed distinct feedback. I could enter the target height without starting over. Making the tabletop usable in the AR path remained unfinished.