perf(ios): reuse prepared runner in Settings smoke

[thymikee]

Summary

Keep the preflight daemon alive for the immediately following iOS Settings replay, so replay uses the XCTest runner prepare ios-runner already started. The previous workflow stopped that runner before the test; baseline CI then spent 143.8 seconds in its first click, mostly on runner restart and rebuild.

One workflow file changed. Addresses the startup cost in #2948; the failed post-tap wait remains under investigation.

Validation

Commit eddfdae9c47cf4883c876c5f32e0571d1edb7b81: pnpm check:affected --run passed. Dedicated iPhone 17 Pro simulator: preflight 38.1 s, same-daemon replay 10.0 s (click 1.3 s); cleanup-before-replay 12.0 s (click 1.4 s) on a warm local cache.

Exact-head iOS job passed. Settings replay step fell from 4m50s to 1m28s; first click fell from 143.8 s to 18.2 s. Uploaded runner log shows one preflight launch and the same PID handling replay commands, with no new build. First attempt still had a 13.1 s snapshot and failed wait; retry passed. Targeted XCTest ran for 13m55s on this PR but was skipped in the baseline, so whole-job times are not comparable.

[github-actions]

Size Report

Metric	Base	Current	Diff
Installed (including dependencies)	4.82 MB	4.82 MB	0 B
Package (unpacked)	4.82 MB	4.82 MB	0 B
Package (download)	1.44 MB	1.44 MB	+11 B

Startup median (7 runs, lower is better):

Scenario	Base	Current	Diff
CLI --version	26.1 ms	27.3 ms	+1.1 ms
CLI --help	79.9 ms	78.4 ms	-1.5 ms

[cubic-dev-ai]

No issues found across 1 file

_{Re-trigger cubic}

[thymikee]

Reviewed eddfdae. I found no code defect: removing the second pnpm clean:daemon lets the Settings replay reuse the runner that prepare ios-runner already started, and the local run backs up the win.

The exact-head proof is still pending. The iOS Smoke Tests job for this commit was still running when I looked. When it finishes, can you confirm from its log that the first click General completes in a few seconds instead of the 143-191 s seen before? A runner log line showing that the replay adopted the prepared runner, not a fresh launch or build, would make this clear. I did not trace the runner adoption path end to end, so that log line is the evidence I am missing.

Coverage (ci.yml) was also still running; this diff does not touch it. There are no conflicts.

[thymikee]

Exact-head iOS job 107967921509 passed, and its uploaded ios-artifacts prove reuse. The preflight runner.log has one xcodebuild test-without-building launch and AGENT_DEVICE_RUNNER_LISTENER_READY at 06:39:46 for PID 30721. The same PID accepted replay targetReset at 06:40:16, snapshot at 06:40:24, and tap at 06:40:40. There is no Settings-attempt runner log or second launch/build; the only later interruption is the intentional cleanup before the gesture replay.

The first click General took 18.189 s, down from 143.840 s in the baseline job. It is not yet a few-second click: the reused runner spent 13.1 s on its first snapshot, including a 4 s system-modal probe timeout and private-AX fallback; the tap itself took 1.1 s. The first wait still failed and retry passed (Settings replay step 1m28s vs 4m50s baseline). I updated #2948 with the startup diagnosis and am keeping the residual snapshot/interaction flake open rather than calling it fixed.

[thymikee]

Thanks, that closes the evidence gap on eddfdae. The exact-head iOS job shows one prepared runner (PID 30721) serving both the preflight and the Settings replay, with no second launch or build, and the Settings step dropped from 4m50s to 1m28s. That is the behavior this PR claims.

The slow first snapshot and the failed first wait are a separate problem, and #2948 tracks them. They do not block this change.

[github-actions]

PR Preview Action v1.8.1
Preview removed because the pull request was closed.
2026-09-25 07:58 UTC