ios-device: support Wi-Fi (network-paired) devices

[onevcat]

Context

PR #93 adds the sim-use ios-device backend: physical iPhones/iPads driven through com.apple.accessibility.axAuditDaemon.remoteserver over usbmux lockdown. That surface currently requires a USB data connection — a device paired over Wi-Fi ("Connect via network" in Xcode) is invisible to it.

Observed with a network-paired iPhone (visible to Xcode and devicectl, absent from the USB bus):

$ sim-use ios-device devices
No physical iOS devices connected.

Wi-Fi support is feasible — nothing in the stack is USB-only in principle (Xcode's Accessibility Inspector drives network devices over this same daemon) — but it is real work in two of the backend's three layers.

What blocks it today

1. Discovery. FBDeviceControl's AMDevice subscription only surfaces USB-attached devices. usbmuxd itself tracks network-paired devices (that is how Xcode sees them), and AMDeviceNotificationSubscribeWithOptions can include them; idb just never asks. Options: patch our idb build to subscribe with network devices included, or bypass FBDeviceControl for discovery and speak the usbmuxd wire protocol directly (ListDevices / ReadPairRecord / Connect — small, plain TCP to /var/run/usbmuxd, no root needed; pymobiledevice3 demonstrates the whole stack in userland).

2. Transport TLS. The DTX transport deliberately writes plaintext to the raw socket, which works over USB because lockdownd answers StartService with EnableServiceSSL: false there. Over the network lockdownd enforces TLS on the service stream (pair-record certificates), so plaintext frames get the connection dropped. Supporting Wi-Fi means terminating that TLS ourselves on the raw socket — full duplex, since the pipelined reader/writer design is what makes ui usably fast. (FBAMDServiceConnection's built-in SSL context is not an option: reading and writing it from two threads fails the socket, which is why the transport owns the raw fd in the first place — see PR feat: drive physical iOS devices over the accessibility audit daemon #93's notes.) The pair record is obtainable without root via usbmuxd's ReadPairRecord.

3. Latency and session stability. A tree walk is hundreds of round trips; Wi-Fi RTT is an order of magnitude above USB. The 16-deep pipelining should amortize most of it (expect ~1.5–3× wall clock, not 10×). The sharper edge is that element handles die with the connection — one Wi-Fi drop invalidates the whole session, which hurts an agent's observe → act → verify loop more than the added latency does.

Shape of the work

• Surface network-paired devices in discovery (idb subscription patch, or a small native usbmuxd client)
• Pair-record TLS over the raw service socket, full duplex under the existing pipelined reader
• Mark transport type in ios-device devices output (usb / network)
• Reconnect-and-retry semantics for dropped sessions, or at least a crisp error that tells the agent to re-run ui
• Measure: full-tree wall clock over Wi-Fi vs USB on the same device/screen

Non-goals

• Replacing USB as the default. USB stays the recommended path; Wi-Fi is opt-in for setups where a cable is impractical.
• iOS 17+ CoreDevice / RemoteXPC tunnels. The audit daemon lives on classic lockdown; no DDI or tunnel daemon is needed, and that property is worth keeping.

[onevcat]

Field evidence that reshapes the priority and the design, from an attempted smoke test of #93 on a corporate-managed Mac:

Endpoint security (CrowdStrike Falcon device control) can deny all of an iPhone's USB data interfaces while leaving enumeration intact. Observed state: the device enumerates in ioreg (configuration negotiated), but no driver binds to the usbmux, NCM, or PTP interfaces; usbmuxd's device list stays empty at 0.3 s polling granularity across replugs; Finder never sees the device; no NCM en* interface appears. Xcode meanwhile drives the same device fine — over its network CoreDevice/RemoteXPC pairing. The phone's trust prompt still fires on USB plug-in, but it is delivered over Wi-Fi (it stops firing with the phone's radios off), so USB pairing can never complete or persist.

Two consequences for this issue:

1. On such hosts, Wi-Fi is not a convenience — it is the only viable transport, which strengthens the case for this work.
2. The usbmuxd network path sketched above has a bootstrap problem in exactly this environment: usbmuxd only discovers network devices after Finder's "Show this iPhone when on Wi-Fi" is enabled, and enabling that toggle requires one working USB session. CoreDevice/RemoteXPC pairs over the network without any USB bootstrap (pairing-code flow), which is how Xcode escapes the trap — but speaking RemoteXPC (tunnel + HTTP/2 + XPC serialization) is a substantially larger transport than pair-record TLS over usbmuxd. Worth evaluating both before committing: usbmuxd-TLS covers the personal-Mac case cheaply; RemoteXPC covers the managed-Mac case at real cost.