L
Hive
tuist run always fails with “Unable to boot device in current state: Booted”
GitHub issue · Open
Source
tuist/tuist #9072
Updated
Jun 11, 2026
Domains
CLI
What happened?
tuist run always runs xcrun simctl boot twice. Once to install the app on the device and again before running it. The second always fails with Error: Unable to boot device in current state: Booted
Expected behavior: Tuist should either skip the boot step before launch if the simulator is already booted, or only boot once during the entire run flow.
How do we reproduce it?
- Run
tuist run -scheme <scheme_name> --device "iPhone 17" - Select a simulator device when prompted
- Observe the error when it attempts to boot the simulator again before launching.
Error log
# First boot succeeds
2026-01-07T10:02:25 debug: /usr/bin/xcrun simctl boot 61CE0BB3-8D17-4EDE-89F1-4299BBFBDB4B
# Install succeeds
2026-01-07T10:02:26 debug: /usr/bin/xcrun simctl install 61CE0BB3-8D17-4EDE-89F1-4299BBFBDB4B ...
# Second boot fails
2026-01-07T10:02:39 debug: /usr/bin/xcrun simctl boot 61CE0BB3-8D17-4EDE-89F1-4299BBFBDB4B
Error: Unable to boot device in current state: Booted
A9B6C0C5-75CC-4C30-8B8F-976F5774D0AE.log
macOS version
26.2
Tuist version
4.119.3
Xcode version
26.2 (17C52)
L
D
dosubot[bot]
Jan 7, 2026
Hi @npckenjamin! I’m Dosu and I’m helping the tuist team.
Tuist runs xcrun simctl boot twice during tuist run—once before installing the app and again before launching it. The second attempt fails with “Unable to boot device in current state: Booted” because the simulator is already running. This happens because the run flow calls the boot logic twice, but the underlying implementation in Tuist’s SimulatorDevice checks if the simulator is already booted and skips the boot command unless the forced flag is set. If forced, it ignores the error if the device is already booted, so the error is non-blocking and can be safely ignored in most cases. You can see this logic in the SimulatorController and SimulatorDevice implementation.
There isn’t a documented workaround or configuration to avoid the double boot, but since the error doesn’t prevent the app from launching, you can ignore it for now. For a more robust solution, Tuist could refactor the run flow to only boot once or reuse the already booted device object.
To reply, just mention @dosu.
Share context across your team and agents. Try Dosu.
