Summary. On an iPad simulator the devicekit runner
(com.mobilenext.devicekit-iosUITests.xctrunner) starts, is granted a scene, and then
terminates on its own after roughly 25-30 seconds without ever serving /health. On an
iPhone simulator, on the same host and the same runtime, it serves /health in about 5
seconds. Every mobilecli command that needs the agent therefore fails on iPads:
dump ui, screenshot, and the io verbs.
The user-visible error is timed out waiting for WebDriverAgent to be ready, which is
misleading in two ways: the agent is mobilecli's own devicekit runner (not Appium's
WebDriverAgent), and it is not a timeout — the process is already gone.
Reproduction
# iPad — fails
xcrun simctl boot <iPad-udid>
mobilecli agent install --device <iPad-udid> # "Agent installed successfully"
mobilecli dump ui --device <iPad-udid>
# -> {"status":"error","error":"failed to start agent on device <udid>:
# timed out waiting for WebDriverAgent to be ready; agent stderr: ..."}
# iPhone — works, same host, same runtime, same agent version
mobilecli dump ui --device <iPhone-udid> # -> full element tree in ~10sThe agent exits with nobody killing it
To rule out mobilecli's own 20s readiness budget as the cause, I launched the runner
directly, the same way SimulatorDevice.StartAgent does, and never terminated it:
SIMCTL_CHILD_DEVICEKIT_LISTEN_PORT=13140 \
xcrun simctl launch --terminate-running-process <iPad-udid> \
com.mobilenext.devicekit-iosUITests.xctrunner
# then poll: xcrun simctl spawn <udid> launchctl list | grep xctrunner
# curl http://localhost:13140/health
| device |
runtime |
runner lifetime |
/health |
| iPhone 17 Pro |
iOS 26.5 |
survives |
OK after ~5s |
| iPad (A16) |
iOS 26.5 |
gone by ~25-30s |
never served (polled 180s) |
| iPad Pro 11-inch (M4) |
iOS 26.5 |
gone by ~25-30s |
never served |
| iPad (A16) |
iOS 27.0 |
gone by ~25-30s |
never served |
| iPad Air 13-inch (M4) |
iOS 27.0 |
gone by ~25-30s |
never served |
--stderr / --stdout captured from simctl launch were both empty. The simulator's
own log shows the runner starting normally —
devicekit-iosUITests-Runner: (XCTestCore) Running with configuration <XCTestConfiguration>
— then SpringBoard reporting the scene invalid and, ~20s later,
testmanagerd: Deallocating <XCTestSession> pid <n>:
[FBSceneManager:sceneID:com.mobilenext.devicekit-iosUITests.xctrunner-default]
Update failed: FBSceneErrorDomain code 1 ("operation-failed")
NSUnderlyingError: FBWorkspace code 1; "Scene client is invalid."
contentState:notReady hasParent:NO
What I ruled out
- Not the iOS runtime. iPads fail identically on 26.5 and 27.0.
- Not the mobilecli version. Same on
0.3.85 and 1.0.11 (agent 1 and 0.0.27).
- Not the 20s readiness budget. The runner dies at ~25s when we launch it and nobody
kills it; six consecutive dump ui attempts converged at ~25s rather than improving.
- Not port contention. Fails with the iPad as the only booted device.
- Not warm-vs-cold. A freshly booted iPhone succeeds in ~13s.
- Not the runner's packaging. Its
Info.plist declares UIDeviceFamily = [1, 2],
iPad orientations (UISupportedInterfaceOrientations~ipad), and a
_XCTRunnerAppDelegate scene delegate.
devices/simulator.go's StartAgent and devicekit's WaitForAgentWithDiagnostics contain
no device-family branching, which is consistent with this being an untested path on iPad
rather than a deliberate difference.
Environment
- macOS 26.x (Darwin 25.6.0), Apple silicon
- Xcode 27.0 (27A266a); runtimes iOS 26.5 (23F77) and iOS 27.0 (24A434)
mobilecli 1.0.11 (also reproduced on 0.3.85), run via npx -y mobilecli@<version>
Also, possibly a separate issue
A newly created simulator is not discoverable for a while: xcrun simctl reports it
Booted, mobilecli devices omits it, and any command against its UDID returns
error finding device: device not found. It appears in mobilecli devices after a delay.
Happy to split this into its own issue if you prefer.
Summary. On an iPad simulator the devicekit runner
(
com.mobilenext.devicekit-iosUITests.xctrunner) starts, is granted a scene, and thenterminates on its own after roughly 25-30 seconds without ever serving
/health. On aniPhone simulator, on the same host and the same runtime, it serves
/healthin about 5seconds. Every
mobileclicommand that needs the agent therefore fails on iPads:dump ui,screenshot, and theioverbs.The user-visible error is
timed out waiting for WebDriverAgent to be ready, which ismisleading in two ways: the agent is mobilecli's own devicekit runner (not Appium's
WebDriverAgent), and it is not a timeout — the process is already gone.
Reproduction
The agent exits with nobody killing it
To rule out mobilecli's own 20s readiness budget as the cause, I launched the runner
directly, the same way
SimulatorDevice.StartAgentdoes, and never terminated it:/healthOKafter ~5s--stderr/--stdoutcaptured fromsimctl launchwere both empty. The simulator'sown log shows the runner starting normally —
devicekit-iosUITests-Runner: (XCTestCore) Running with configuration <XCTestConfiguration>— then SpringBoard reporting the scene invalid and, ~20s later,
testmanagerd: Deallocating <XCTestSession> pid <n>:What I ruled out
0.3.85and1.0.11(agent1and0.0.27).kills it; six consecutive
dump uiattempts converged at ~25s rather than improving.Info.plistdeclaresUIDeviceFamily = [1, 2],iPad orientations (
UISupportedInterfaceOrientations~ipad), and a_XCTRunnerAppDelegatescene delegate.devices/simulator.go'sStartAgentanddevicekit'sWaitForAgentWithDiagnosticscontainno device-family branching, which is consistent with this being an untested path on iPad
rather than a deliberate difference.
Environment
mobilecli1.0.11 (also reproduced on 0.3.85), run vianpx -y mobilecli@<version>Also, possibly a separate issue
A newly created simulator is not discoverable for a while:
xcrun simctlreports itBooted,mobilecli devicesomits it, and any command against its UDID returnserror finding device: device not found. It appears inmobilecli devicesafter a delay.Happy to split this into its own issue if you prefer.