[bitsandfoxes]

The iOS simulator provider no longer runs simctl terminate before the first launch after it boots the simulator, and every other terminate is bounded to 60 s. The first launch no longer stalls for minutes.

In 150 sentry-unity Run iOS logs, the simctl terminate before the first launch stalled for 59–430 s in 24 legs (16%), for example 349 s here. Later terminates never took more than 14 s, even when the app wasn't running. A first attempt waited for simctl bootstatus before that terminate. In this run, bootstatus returned within 1 s on all four legs, yet the first terminate still hung in one of them until the 60 s cap. So the stall isn't a boot that hasn't finished, and waiting for one doesn't help.

How it works now:

• Before the first launch after BootSimulator() actually booted the device, the provider skips the terminate. On a freshly booted simulator, the app can't be running. The flag resets on every boot, restart and disconnect. A simulator that was already booted when the provider connected still gets the terminate.
• Every other simctl terminate is bounded to 60 s, including the one after a run timeout. If the terminate before a launch times out, the launch adds --terminate-running-process, so every launch still starts a fresh process.

Tests/iOSSimulatorRunApplication.Tests.ps1 runs on macOS only. It uses a fake xcrun and runs the real start, restart and disconnect paths. It covers the skip after a boot, the re-arm after a restart, an already-booted simulator, a hung terminate and its fallback, and killing a hung command.

Stacked on #64.

CI evidence: in sentry-unity run 40241909708 (getsentry/sentry-unity#2910, pinned to this commit), every Run iOS leg's first launch started 0 s after "Run log" and later launches within 1–5 s. No terminate timed out, and all 4 legs passed 57/57.

🤖 Generated with Claude Code