iOS 17.5: open --launch-url still leaves the "Open in" alert up in 5/22 runs on 0.21.29: the runner's accept times out (main thread execution timed out) #3861

Summary

Follow-up to #3702, as requested when it was closed. With 0.21.29 on fresh iOS 17.5 simulators, open --launch-url now reads the "Open in “”?" title correctly, but still leaves the alert on screen in 5 runs out of 22. In those runs, the runner times out while pressing Open, so open fails with launch_confirmation_unanswered and no session is opened. Answering by hand with alert accept then also failed in 3 of 4 tries.

Environment

• agent-device 0.21.29 (latest)
• Xcode 27.1, iPhone 15 simulator on iOS 17.5, a new simulator for each run (deleted afterwards), app installed with simctl install, deep link never received before
• Expo development build, custom URL scheme owned by the app
• Same setup as the nightly measurement in iOS 17.5: open --launch-url leaves the "Open in" alert unanswered because the runner reads its title as "0 pages" #3702 (11/11 accepted with 0.21.29-nightly.20261020.76)

Steps

npx agent-device open <bundle-id> --launch-url "<scheme>://..." --platform ios --udid "$SIM" --relaunch --foreground --json --debug
npx agent-device alert get --platform ios --udid "$SIM"
npx agent-device alert accept --platform ios --udid "$SIM"   # only when open failed
npx agent-device wait 'id="<testID>"' 30000 --platform ios --udid "$SIM"

Results

When open fails, it returns this --json output, the same in all 5 runs (local paths and diagnostic ID removed):

{
  "success": false,
  "error": {
    "code": "COMMAND_FAILED",
    "message": "The Simulator has not completed the launch URL for <bundle-id>.",
    "hint": "iOS may still be holding an \"Open in\" prompt, or the answer died with the runner session that raised it. Inspect the current alert before deciding on another action.",
    "details": {
      "reason": "launch_confirmation_unanswered",
      "appBundleId": "<bundle-id>",
      "dispatched": "unknown"
    }
  }
}

The request log contains ios_launch_confirmation_unanswered {"reason":"alert-still-present"}. In each failed run, alert get then returns Open in “RN Template”? (exit 0), so the title is no longer the problem.

In the one failed run where I read the runner log (series 1), the sequence inside open is:

1. The first alert read is sent right after runner startup (health check about 9.8 s) and completes ok=1.
2. The alert accept fails after 10 s: AGENT_DEVICE_RUNNER_COMMAND_FAILED command=alert … error=… "main thread execution timed out".
3. A second alert read completes and finds the alert still present, so open fails.

In series 2, I followed the open hint and ran alert accept by hand in the 4 failed runs:

Because open failed, no session exists afterwards, so the following wait returns SESSION_NOT_FOUND even after a successful alert accept. I did not measure recovery by a second open.

All 17 runs where open returned accepted went on normally: alert get returned alert not found, and wait succeeded.

A second simulator, booted by an unrelated CI job, was running on the same host at least at the start of the measurement, so host load may play a role. I have not established that it does.

Expected

On iOS 17.5, open --launch-url accepts the "Open in" alert on every run, as it did with the nightly and does on iOS 27.0. If pressing the button can time out on a runner that has just started, I would expect it to be retried within open's own budget rather than failing the open.

Related

• iOS 17.5: open --launch-url leaves the "Open in" alert unanswered because the runner reads its title as "0 pages" #3702 / fix(ios): report the alert's own title and surface an unanswered launch confirmation #3732: title read as 0 pages, fixed in 0.21.29.
• iOS alert activation can tap after the command deadline #2956 (closed): alert activation tapping after the command deadline.
• ios(runner): a 1 s readiness preflight abandons a busy runner command and the next connect stalls behind it, failing waits on cold hosts #2475 (closed): 1 s readiness preflight abandoning a busy runner command on cold hosts.