Context
Harness runs unreliably on small CI hosts (e.g. GitHub macos-latest: 3 vCPU / 7 GB); a common symptom is the app failing to connect to the bridge shortly after simulator boot.
prepareSimulator in packages/platform-ios/src/instance.ts boots the simulator and waits with xcrun simctl bootstatus <udid> -b (packages/platform-ios/src/xcrun/simctl.ts waitForBoot). bootstatus -b returns as soon as the device reports Booted, but SpringBoard and the first-boot daemons keep consuming CPU for a while afterwards. On a 3-core host the app is then installed and launched into a simulator that is still busy, which stretches JS evaluation and can push startup past bundleStartTimeout / readyTimeout.
Proposal
Add a bounded "settle" step after waitForBoot, applied on constrained hosts (reuse the host-capability thresholds from startup-strategy.ts):
- Poll a direct responsiveness probe, e.g.
xcrun simctl spawn <udid> launchctl list, and proceed once two consecutive calls complete under ~300 ms; and/or
- wait until
os.loadavg()[0] drops below cores × 1.5;
- cap the wait (e.g. 45 s) so a persistently busy host does not stall startup, and record the settle duration in diagnostics.
This should apply both when Harness booted the simulator and when it found one already Booting.
Files
packages/platform-ios/src/instance.ts (prepareSimulator)
packages/platform-ios/src/xcrun/simctl.ts (waitForBoot)
packages/platform-ios/src/startup-strategy.ts
Part of a broader effort to make Harness reliable on constrained CI runners.
Context
Harness runs unreliably on small CI hosts (e.g. GitHub
macos-latest: 3 vCPU / 7 GB); a common symptom is the app failing to connect to the bridge shortly after simulator boot.prepareSimulatorinpackages/platform-ios/src/instance.tsboots the simulator and waits withxcrun simctl bootstatus <udid> -b(packages/platform-ios/src/xcrun/simctl.tswaitForBoot).bootstatus -breturns as soon as the device reportsBooted, but SpringBoard and the first-boot daemons keep consuming CPU for a while afterwards. On a 3-core host the app is then installed and launched into a simulator that is still busy, which stretches JS evaluation and can push startup pastbundleStartTimeout/readyTimeout.Proposal
Add a bounded "settle" step after
waitForBoot, applied on constrained hosts (reuse the host-capability thresholds fromstartup-strategy.ts):xcrun simctl spawn <udid> launchctl list, and proceed once two consecutive calls complete under ~300 ms; and/oros.loadavg()[0]drops belowcores × 1.5;This should apply both when Harness booted the simulator and when it found one already
Booting.Files
packages/platform-ios/src/instance.ts(prepareSimulator)packages/platform-ios/src/xcrun/simctl.ts(waitForBoot)packages/platform-ios/src/startup-strategy.tsPart of a broader effort to make Harness reliable on constrained CI runners.