Repository navigation
iOS 17.5: open --launch-url leaves the "Open in" alert unanswered because the runner reads its title as "0 pages" #3702
Description
Summary
On an iOS 17.5 simulator, open --launch-url does not answer the first-deep-link confirmation alert ("Open in “”?", buttons Cancel / Open). The runner reads the alert's buttons correctly but reports its title as 0 pages, so answerLaunchConfirmation rejects it as alert-unrecognized, leaves it on screen, and open still exits 0 with no error. On iOS 27.0 the same sequence reads the right title and accepts the alert.
Environment
- agent-device 0.21.28
- Xcode 27.0, iPhone 15 simulator, freshly created, app installed with
simctl install, deep link never received before - Expo development build, custom URL scheme owned by the app
Steps
npx agent-device open <bundle-id> --launch-url "<scheme>://..." --platform ios --udid "$SIM" --relaunch --foreground --json --debug
npx agent-device wait 'id="<testID>"' 15000Results
| iOS | Trials | open --launch-url … --json |
Alert |
|---|---|---|---|
| 17.5 | 2/2 | exit 0, no launchConfirmation, warning initial interactive snapshot failed (COMMAND_FAILED: app '<bundle-id>' is not running) |
stays on screen; alert get returns Open in “RN Template”?; alert accept then wait succeed |
| 27.0 | 2/2 | exit 0, launchConfirmation: "accepted" |
accepted |
Request log (data.requestLogPath) on iOS 17.5:
ios_launch_confirmation_unanswered {"reason":"alert-unrecognized","title":"0 pages","buttons":["Cancel","Open"]}
Analysis (unverified)
launch-confirmation.js only accepts a title matching ^Open in [“"].+[”"]\?$. The title comes from preferredAlertTitle in RunnerTests+Alert.swift, which returns the first non-empty, non-button descendant label of the alert root. On iOS 17.5 that seems to pick up the Home Screen page indicator ("0 pages") rather than the alert title. A later alert get does return the right title.
Expected
- On iOS 17.5,
open --launch-urlrecognizes and accepts the "Open in" alert, as it does on iOS 27.0. - When an alert is present but not recognized,
openreports it (launchConfirmationwith anunansweredoutcome and a hint such asalert accept) instead of exiting 0 silently.
Related
open --launch-urlshould answer the iOS "Open in <app>?" confirmation #3076 / feat(open): answer the iOS launch confirmation for --launch-url #3084 introduced the launch confirmation answer; fix(apple): read the launch confirmation whenever the open cannot see the app #3115 and open --launch-url: a post-open target discovery that fails on its deadline must not skip the launch confirmation read #3096 covered when it is read. None of them covers the title being misread.- fix(ios): handle delayed launch confirmations without stopping XCTest #3682 (open) reads system alerts before querying a stopped app, validated on iOS 26.2. It does not change
preferredAlertTitle, so it is not expected to fix the0 pagestitle on iOS 17.5. - iOS alert resolution reads every element of the app window when a popover is found #2905 (open) notes that
preferredAlertTitlewalks every descendant of the resolution root, from a performance angle.
Activity
MoogyG commentedon Oct 16, 2026
Follow-up measurement: the failure is intermittent on iOS 17.5, not systematic.
Same setup (agent-device 0.21.28, Xcode 27.0, iPhone 15 simulators freshly created, app installed with
simctl install, deep link never received before):open --launch-url … --jsonios_launch_confirmation_unanswered,alert-unrecognized, title0 pages);launchConfirmation: "accepted"the other 3 timeslaunchConfirmation: "accepted"4 times out of 4When the alert is left,
alert getthenalert acceptin the same session succeed every time (6/6). The successful iOS 17.5 runs were not obviously tied to one setup: one followedexpo run:ioson the same simulator, the others usedsimctl installonly. A fix should therefore be validated over several fresh iOS 17.5 simulators, not a single run.thymikee commentedon Oct 16, 2026
Triage: bug; actionable without more input from you. Thanks, the 8-of-11 numbers on 17.5 help.
Two parts. The runner's alert title read walks every descendant of the resolution root and can return a SpringBoard label ("0 pages") instead of the alert's own title. And
openshould surface an unanswered launch confirmation with analert accepthint, not exit 0 silently. The fix reads the title from the alert itself, and validation covers several fresh iOS 17.5 simulators, as you suggest.thymikee commentedon Oct 16, 2026
An agent is picking this up; the PR will link here.
thymikee commentedon Oct 20, 2026
#3732 is in nightly
0.21.29-nightly.20261019.75(npm i -g agent-device@nightly). Two changes: the runner reads the alert's own title, andopenno longer exits 0 while the launch confirmation is still on screen. It reportsios_launch_confirmation_unansweredwith analert accepthint instead. We had no iOS 17.5 runtime, so please repeat your 11-run table on fresh 17.5 simulators with the nightly:--jsonoutput ofopenMoogyG commentedon Oct 20, 2026
Repeated the measurement with the nightly on fresh iOS 17.5 simulators: the alert is accepted on every run.
Setup: Xcode 27.1, one iPhone 15 simulator created per run (deleted afterwards), app installed with
simctl install, deep link never received before, thenopen <bundle id> --launch-url "<scheme>://…" --platform ios --udid <udid> --relaunch --foreground --json --debug.open --launch-url … --json0.21.29-nightly.20261020.76launchConfirmation: "accepted"11 times out of 11;alert getafterwards:alert not found; app loads0.21.28(control, same host and setup)launchConfirmation, warninginitial interactive snapshot failed (COMMAND_FAILED: app '…' is not running); request logios_launch_confirmation_unanswered {"reason":"alert-unrecognized","title":"0 pages","buttons":["Cancel","Open"]}6 times out of 6The 0.21.28 control was needed because the host moved from Xcode 27.0 to 27.1 since my earlier table; on 27.1 the old version fails every time, so the change comes from #3732, not from Xcode.
Nightly output of a run (all 11 identical apart from ids and timings,
openin 9–10 s):{"success":true,"data":{"appBundleId":"…","platform":"ios","launchConfirmation":"accepted","message":"Opened: …"}}Since no run left the alert up, the new
unanswered/alert-unrecognizedreporting path was not exercised.thymikee commentedon Oct 21, 2026
Thanks, the 11-of-11 run against the 0.21.28 control on the same Xcode settles it. #3732 shipped in 0.21.29, so I'm closing this. If an alert is ever left up again,
opennow reportsios_launch_confirmation_unanswered; please open a new issue with that--jsonoutput.