Context
PR #1375 adds a small usbmux client so agent-device can reach the XCTest runner on physical iOS devices where CoreDevice is unavailable. Modern CoreDevice devices currently take a different path: run devicectl to discover a tunnel IP, cache it, refresh it after failures, and connect to the runner over that address.
Now that the usbmux transport exists, investigate whether cable-connected physical iOS devices can share one runner transport. The goal is deletion and simplification, not a public iproxy clone.
Experiments
- Force a current CoreDevice-capable physical iPhone through usbmux for a complete runner lifecycle: open, snapshot, interaction, screenshot, and close.
- Compare connection reliability and latency with the current devicectl tunnel-IP route, including reconnects and runner restarts.
- Determine how usbmuxd represents paired Wi-Fi devices and whether the runner remains reachable after USB is disconnected.
- Exercise multiple attached devices and confirm UDID-to-device selection is unambiguous.
- Verify failure behavior for locked, disconnected, unpaired, and unavailable devices.
- Measure the implementation and npm bundle delta if the old runner tunnel-IP routing and cache are removed.
Desired outcome
If the evidence supports it, hide physical runner connection details behind one small internal transport interface and use usbmux as the primary route. Remove the CoreDevice tunnel-IP lookup, cache, invalidation, and retry code that exists only to locate the runner endpoint.
Preserve a CoreDevice network fallback if Wi-Fi-only devices cannot use usbmux reliably. CoreDevice readiness and diagnostic calls may still be needed; this exploration targets runner endpoint transport only.
Acceptance criteria
- Results document behavior on a modern USB-connected physical iPhone and a Wi-Fi-only or USB-disconnected paired device.
- The proposed route preserves current device selection, session, timeout, cancellation, and error semantics.
- The resulting design has one private runner-command interface; callers do not choose between network and usbmux transports.
- Any implementation demonstrates concrete deletion or simplification relative to the current tunnel-IP route.
- Live device evidence accompanies an implementation PR.
Non-goals
- A public generic port-forward command without a second concrete product use case.
- Reverse forwarding for Metro or React DevTools; the current usbmux connection direction is host to device.
- Reimplementing lockdownd services such as installation proxy, AFC, syslog relay, or device management.
- Adding clipboard, launch argument, or deep-link parity in this issue; those may be separate runner capability issues after feasibility is established.
Related: #1361, #1335, PR #1375.
Context
PR #1375 adds a small usbmux client so agent-device can reach the XCTest runner on physical iOS devices where CoreDevice is unavailable. Modern CoreDevice devices currently take a different path: run devicectl to discover a tunnel IP, cache it, refresh it after failures, and connect to the runner over that address.
Now that the usbmux transport exists, investigate whether cable-connected physical iOS devices can share one runner transport. The goal is deletion and simplification, not a public iproxy clone.
Experiments
Desired outcome
If the evidence supports it, hide physical runner connection details behind one small internal transport interface and use usbmux as the primary route. Remove the CoreDevice tunnel-IP lookup, cache, invalidation, and retry code that exists only to locate the runner endpoint.
Preserve a CoreDevice network fallback if Wi-Fi-only devices cannot use usbmux reliably. CoreDevice readiness and diagnostic calls may still be needed; this exploration targets runner endpoint transport only.
Acceptance criteria
Non-goals
Related: #1361, #1335, PR #1375.