Xcode 26.6 iOS Simulator Download Failed: 2026 Remote Mac Fix

An Xcode installation can be healthy while its Simulator runtime is absent. An SDK being visible in project settings does not prove that the matching runtime is installed and registered with CoreSimulator.

Use three independent tests:

xcodebuild -version
xcode-select -p
xcrun simctl list runtimes

Then test the device layer:

xcrun simctl list devices
xcrun simctl boot "<device-name-or-udid>"

The evidence has four possible meanings:

Apple documents additional Simulator installation through Xcode and command-line workflows. Use the official additional Simulator documentation to confirm the currently available platform and runtime choices.

Do not treat an SDK label in the project editor as proof that an iOS Simulator runtime exists. This distinction prevents an unnecessary project change or a destructive Xcode reinstall.

Multiple Xcode versions are common on build hosts. The graphical application you opened may be Xcode 26.6, while the terminal still points to another Developer Directory.

Check both paths:

xcode-select -p
xcrun --find xcodebuild
xcodebuild -version

If the selected path does not match the Xcode application you intend to use, set it explicitly:

sudo xcode-select --switch "/Applications/<Xcode-26.6>.app/Contents/Developer"

Replace the placeholder with the actual application path on your node. Do not apply a global switch on a shared machine until you know which jobs depend on the current selection. A CI host with separate jobs may need per-job environment control rather than one permanent system-wide choice.

Confirm the application can complete its first-run setup:

sudo xcodebuild -license accept
sudo xcodebuild -runFirstLaunch

Run these commands only after confirming the selected Developer Directory. The Apple documentation for downloading and installing additional Xcode components is the reference point for the supported component workflow.

A useful acceptance condition is simple:

• xcodebuild -version reports the intended Xcode version.
• xcode-select -p points into that same application.
• First-launch setup exits without an error.
• The Xcode Components view and command line refer to the same installation.

If those checks pass, stop changing the toolchain. Move to runtime discovery.

A download that remains on Preparing can have several causes. User reports in the Apple Developer Forums discussion about Simulator downloads are useful as symptom reports, but they do not establish a general Apple-confirmed outage.

Treat the screen as a symptom, not a diagnosis. Record:

• The exact runtime or platform requested.
• The time of the attempt.
• The visible error text.
• Any error code.
• The destination Mac and active Xcode path.
• Whether the same account can download another component.

Then test the layers in order.

Check Xcode Components

Open Xcode’s component or platform download area and confirm whether the requested runtime is listed. If the item disappears, returns to the download list, or changes state without installation, capture a screenshot and the relevant system log before retrying repeatedly.

Do not infer that a forum report means the service is broadly unavailable. A remote node may have a blocked egress path, a proxy that interrupts large downloads, or a DNS resolver returning an unusable route.

Check command-line behavior

Use the command-line path supported by the installed Xcode version. First inspect the available options:

xcodebuild -help | grep -E "downloadPlatform|exportPlatform|importPlatform"

If the options are available, start a controlled download:

xcodebuild -downloadPlatform iOS -exportPath "<export-directory>"

The exact platform list and export behavior can change with Xcode releases. Confirm the syntax from the installed tool and Apple’s component documentation instead of copying a command from an older build host.

Check the remote network

On a remote Mac, inspect the path between the node and Apple’s component services. Check DNS resolution, outbound firewall policy, HTTP or HTTPS proxy settings, and any hosts-file overrides. Do not remove entries automatically. Save a copy first.

Useful evidence includes:

scutil --dns
networksetup -getwebproxy "<network-service>"
networksetup -getsecurewebproxy "<network-service>"
cat /etc/hosts

The output is diagnostic data, not proof that a particular domain is faulty. Redact credentials and internal addresses before sharing logs.

Keep the error domain, error code, timestamp, requested runtime build, and active Xcode path together. A single screenshot rarely distinguishes a catalog problem from a blocked download.

Retry only after one variable changes. For example, test the same runtime after correcting the proxy, then compare the new result with the original log. Repeated retries without a changed condition produce noise and can leave a node with unclear partial state.

When the project builds but xcrun simctl list runtimes does not show the required iOS runtime, the build SDK and Simulator runtime are out of sync.

First compare the graphical and command-line views:

xcrun simctl list runtimes
xcrun simctl list devices

Then inspect the Xcode Components view. You are looking for one of three states:

1. The runtime is absent from both Xcode and simctl.
2. Xcode shows a downloaded component, but simctl does not list it.
3. simctl lists the runtime, but devices fail to boot.

Each state has a different response.

For the first state, use the supported Xcode or xcodebuild download path. For the second, complete the import or first-launch process before creating devices. For the third, create a disposable test device and check whether the failure is limited to an existing device data set.

Do not begin by deleting CoreSimulator data. Existing devices, test artifacts, logs, and local state may be removed. If the node is shared, that action can also disrupt another job.

A safer sequence is:

xcrun simctl shutdown all
xcrun simctl list devices

Restart Xcode and the Simulator service path, then test a newly created device. Use the Apple build-and-run reference to validate the final build and launch flow.

If a runtime is present but marked unavailable, record the complete output before taking action. Do not copy a runtime directory from another machine by hand. A visible folder does not prove that the package was fully imported or registered.

A second Mac can supply a runtime to a remote Mac, but use Apple’s supported export and import path. Directly copying a partial runtime directory is difficult to audit and may leave registration incomplete.

On a Mac with a working download path, export the requested platform:

xcodebuild -downloadPlatform iOS -exportPath "<export-directory>"

Transfer the resulting export through your approved administrative channel. Record:

• The source Mac and active Xcode path.
• The requested platform and runtime build.
• The export directory contents.
• The transfer result and checksum.
• The target Mac and destination path.

On the target node, inspect the installed command syntax first:

xcodebuild -help | grep -E "importPlatform|downloadPlatform"

Then import using the syntax exposed by that Xcode installation, for example:

xcodebuild -importPlatform "<exported-platform-package>"

Do not assume that an import created for one Xcode branch is valid for every other branch. Confirm the active Xcode, platform version, and architecture variant on both Macs. The official Xcode component guide should remain the source of truth when command options differ.

After import, verify in this order:

xcrun simctl list runtimes
xcrun simctl list devices
xcrun simctl boot "<new-test-device>"

A successful file transfer is not a successful runtime installation. The runtime must be visible to CoreSimulator and usable by a device.

This method is particularly useful when several remote Macs share the same restricted network. It reduces repeated downloads, but it does not remove the need to validate each target node. A corrupted transfer, mismatched Xcode, or incomplete first launch can still produce a local failure.

Before clearing CoreSimulator data, reinstalling Xcode, or deleting system resources, create a recovery record. Include the command output, Xcode path, runtime state, logs, and any project-specific test result.

Use this decision matrix:

A full Xcode reinstall is not the default answer to an iOS Simulator download failure. It becomes reasonable only when the application bundle, selected Developer Directory, or component installation is demonstrably damaged and you have a recovery path.

The same applies to deleting CoreSimulator data. Back up any required device data and test artifacts first. If you cannot explain what the deletion is expected to repair, do not run it.

The final test must go beyond a visible runtime list. Use a short acceptance sequence:

• [ ] xcodebuild -version reports the intended Xcode 26.6 installation.
• [ ] xcode-select -p matches that installation.
• [ ] First-launch initialization completes without an error.
• [ ] xcrun simctl list runtimes shows the required iOS runtime.
• [ ] A new test device can be created or listed.
• [ ] The device boots successfully.
• [ ] A minimal test project builds for the Simulator.
• [ ] The real project launches and runs its Simulator tests.
• [ ] The test survives an SSH disconnect.
• [ ] The test is repeated after a Mac restart.
• [ ] Xcode is closed and reopened before the final run.

A node that works only while your SSH session remains open is not ready for CI. A node that works before reboot but fails afterward has not passed operational validation.

For teams managing several machines, keep the runtime build, import record, active Xcode path, and final test result in the node inventory. That record helps you distinguish a bad package from a bad host instead of repeating the same investigation on every machine.

For a broader remote development setup, you can compare available CALMVPS remote Mac options with your required Xcode and Simulator workflow. The relevant question is not merely whether macOS is reachable. It is whether the node can retain a clean toolchain and pass the reboot and real-project checks above.

Continuing to repair a heavily modified Mac has a cost. Previous Xcode versions, partial runtime downloads, deleted Simulator data, changed proxies, and system-wide toolchain switches can hide the original fault.

A clean remote Mac gives you a controlled comparison:

1. Confirm the Xcode application and selected Developer Directory.
2. Complete first launch.
3. Download or import the required runtime.
4. Run simctl and device boot checks.
5. Execute the real project’s Simulator tests.
6. Reboot and repeat the test.

If the clean node succeeds while the original node fails, isolate or rebuild the original instead of continuing destructive cleanup. If both fail at the same download stage, investigate the shared network or Apple component availability before changing Xcode again.

This is also where CALMVPS pricing information can help you compare a temporary clean-node test with continued maintenance of a damaged Mac. Renting is not automatically the right choice for every workload. A long-running, stable heavy-build environment may justify owning and maintaining dedicated hardware, and workflows requiring local physical interfaces still need a physical Mac.

For short-lived recovery, release validation, or a clean comparison node, however, a rented Mac can avoid three recurring problems in the current setup: uncertain hardware state, repeated local reinstallation work, and the delay of preparing another physical machine. You can test the complete Xcode 26.6 workflow first, then decide whether the node should become a continuing CI resource or be discarded after the incident is resolved.

When the current Mac has been repeatedly reinstalled or cleaned, start with a clean remote Mac and establish a trustworthy baseline before you make another destructive change.