A hung simctl shows a network error, and the device list empties and refills #25707

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

Server and web: Device panel and onboarding, local device host (macOS)

Steps to reproduce

This happened on my Mac when CoreSimulatorService stopped answering after about two days of uptime: every xcrun simctl call hung, including simctl help. To reproduce it without waiting for that, pause the service and resume it afterwards:

1. Quit Simulator.app. Find the service with launchctl list | grep -i coresimulator, then kill -STOP <pid>.
2. On macOS, start a dev server and open the Device panel. Click Refresh devices a few times.
3. Resume with kill -CONT <pid>.

For the case where simctl fails at once rather than hanging, I put a fake xcrun first on the dev server's PATH that exits 1 with CoreSimulator's error. (The server rebuilds PATH from the login shell in fixPath, so the test server also needs SHELL pointed at a wrapper that prepends it.)

Reproduced on main at d487078f11 (the paused service) and 90c455ff8f (the fake failure), macOS 27.0.1.

Expected behavior

The panel says the simulator service isn't answering, and keeps showing the devices it last found while it can't list them.

Actual behavior

When simctl hangs:

• After 15 s the panel shows "Device list failed: Could not communicate with device support. Try refreshing devices. Check the host connection and network access, then retry." Nothing points at the simulator service, and the network advice points the wrong way. hubJson (apps/server/src/device/DeviceHubOperations.ts:61) gives up after 15 s and maps a timeout, a bad status and a decode failure all to request_failed (packages/contracts/src/device.ts:523).
• Each refresh shows the old list again, then replaces it with the error card when it fails 15 s later.
• Each refresh leaves another stuck xcrun simctl list devices --json under the device hub (1 → 2 → 3 in my test). They clear once the service recovers.

When simctl fails at once:

• The hub answers with simulators: [] and an errors entry, and refresh in DeviceService.ts (around line 402) replaces the host's devices with the empty list. The panel says "No simulators or emulators were found" until a refresh succeeds and brings them all back.
• Onboarding's "Check simulator support" step says "Xcode is installed, but no iOS Simulator is available. Install a runtime in Xcode Settings → Components." (apps/web/src/components/device/DeviceSetup.tsx:110). That points at the wrong fix: the runtimes are installed, and the service isn't answering.

Impact

Minor bug or occasional failure. The fix for the person is restarting CoreSimulatorService, but nothing says so.

Related work

• fix(apple-utils): time out simctl calls instead of hanging expo/expo-device-hub#464 gives the hub's execSimctl a 30 s timeout, matching what serve-sim already uses, with its own error ("xcrun simctl list devices --json did not respond within 30 s; CoreSimulatorService may need restarting"). That fixes the stuck processes. Devin reviewed it with no issues; it's waiting on Expo.
• fix(server): device list warnings keep the hub's error detail #25248 makes the discovery warning show the cause the hub reports. Today it's cut off after "Failed to run xcrun simctl list devices --json:".

Possible fix

• If Add file-backed appearance config for font overrides #464 lands with 30 s, T3's device-list timeout needs to be longer than that (for example 35–40 s), so the hub's timeout error reaches the panel instead of T3 giving up first at 15 s. T3 pins expo-device-hub canaries from Expo's main, so a canary bump after Add file-backed appearance config for font overrides #464 merges would pick it up.
• A distinct timeout message in hubJson, such as "The device hub did not answer within N s", for hubs without Add file-backed appearance config for font overrides #464 or anything else that stops the hub answering.
• Keep the last known devices when the hub's list comes back empty with errors, and show the errors as the warning. This is a product choice, so I'd like your view before sending it.
• The onboarding hint could say the simulator service isn't responding when the hub reports a simctl error, rather than suggesting a missing runtime.

I'm happy to send a PR for the timeout and the message once you've said which of these you want.

Posted by Claude Opus 5.5, an AI agent, on Jackson's behalf.