GitHub announced that its Xcode 27 runner image became generally available on October 15, 2026. The image runs on macOS 27, includes the Xcode 27 toolchain and Apple SDKs, and is available on Apple Silicon runners with the xcode-27 and xcode-27-xlarge labels (GitHub’s announcement).

Symptom: xcodebuild says no Simulator destination matches, or the requested runtime is unavailable.
Fastest fix: Verify the actual runner image and active Xcode first; then compare the installed runtime, available devices, scheme, and destination. Don’t start by reinstalling Xcode or changing project settings.

Who should read this: CI engineers bringing up Xcode 27 in GitHub Actions to run iOS Simulator tests.
iOS developers whose test job cannot match a destination or reports a missing runtime.
DevOps engineers deciding whether a specific test job needs a dedicated remote Mac.

Last updated October 17, 2026. Runner availability and labels were checked against GitHub’s announcement; image contents should be verified against the current runner image README before each diagnosis.

Trace the failure to the right layer

A destination error does not by itself prove that the Simulator app, Xcode installation, or project is broken. First identify where the job stopped:

  • Build failure: compilation or linking stopped before tests could begin.
  • Destination matching failure: xcodebuild started, but none of the available destinations matched the requested platform, device, or OS version.
  • Simulator launch or test failure: a destination was selected, but the device failed to boot or the test failed afterward.

These are different failure classes. Save the complete job log and identify the first failing command before changing anything. GitHub’s workflow run log documentation describes how to open and inspect job logs.

Do not infer the machine from the workflow file alone. Check the job log for the runner label, image information, Xcode path, and failing step. GitHub-hosted images change over time, so a label is not a permanent inventory of installed runtimes or devices. The hosted runner reference explains the runner environment; the Xcode 27 image README is the place to check its current image contents.

Why can a GitHub Actions Xcode 27 Runner fail to find an iOS Simulator?
The requested destination may not match the scheme’s platform, the active Xcode may not be the one you expected, or the image may not contain the requested runtime or device type. Use the failed job’s evidence to distinguish these causes before selecting a fix.

Check whether the scheme can use the requested destination

Start with the exact command from the failed step. Record the scheme, test target, platform, and destination arguments. Then ask Xcode to show the destinations available for that scheme:

xcodebuild \
  -scheme "YourScheme" \
  -showdestinations

Compare the output with the destination supplied to the test command. For example, a destination can request an iOS Simulator by device name and OS version:

-destination 'platform=iOS Simulator,name=Your Device,OS=Your Requested Version'

Treat those values as project-specific inputs, not as guaranteed devices on every runner image. Apple’s Xcode automated testing documentation describes using xcodebuild for automated tests.

Check the project and scheme as a separate piece of evidence:

  • Confirm the scheme is shared and is the one the workflow actually invokes.
  • Confirm the selected test target supports the requested platform. An iOS Simulator destination will not make a target configured for another platform into an iOS test target.
  • Compare the requested device name and OS filter with the available destinations printed by -showdestinations.
  • Look for workflow variables or test scripts that build the destination string dynamically. A stale value can survive even after the runner label changes.

A spelling mismatch, an OS filter that excludes the installed runtime, and an incompatible test target can all produce destination-selection failures. They require different changes. Correct a wrong destination value in the workflow; correct a scheme or target mismatch in the project configuration. Do not change both at once, or you will lose the evidence that identifies the cause.

Verify the runtime and device inventory

A runtime and a device are related, but they are not interchangeable. A Simulator runtime provides an OS version; the device inventory reports Simulator devices available to the active toolchain. The job must have a compatible combination for the requested destination.

Add temporary diagnostic commands before the test step:

xcrun simctl list runtimes
xcrun simctl list devices available

Then compare the output with the -destination value and the relevant entries in the current image README. Capture this output in the same job that fails. A list copied from a different run, image revision, or local Mac cannot establish what the failing runner actually had installed.

How do you confirm which Simulator runtimes are installed on xcode-27?
Run xcrun simctl list runtimes in the failing job, after confirming which Xcode is active. The runner README can help explain the image’s published contents, but the job’s own output is the evidence for that particular run.

Use the evidence to separate these cases:

  • The requested OS version does not appear in the runtime list.
  • The runtime appears, but the requested device type is absent from the available device list.
  • A matching device appears, but the test fails during boot or execution rather than destination matching.

For a missing runtime, decide whether it is appropriate to install an additional component during a short-lived hosted job. Apple documents the supported process in its guide to downloading and installing additional Xcode components. Check the installation time, permissions, and repeatability in your workflow. If each job has to fetch and prepare components, that setup becomes part of the pipeline’s failure surface. Do not assume a downloaded runtime will remain available to a later hosted job.

Confirm the active Xcode and the actual device

A runner can have more than one Xcode installation or a selected developer directory that differs from the one you intended. Check both the selected path and the executable version inside the job:

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

Apple’s command-line tools settings documentation explains how to inspect and configure the active developer directory. Compare the output with the Xcode path and image information in the runner log. If the job sets DEVELOPER_DIR, inspect that value too: it may affect which Xcode the command uses.

Keep these causes distinct:

  • Multiple Xcode installations: the expected version exists, but another installation is active.
  • Wrong active developer directory: xcode-select -p points to an unintended path.
  • Missing platform components: the selected Xcode is correct, but the required runtime or device is absent from that image.

A runner label and an xcodebuild -version result answer different questions. The label requests a runner class; the command reports the toolchain actually used by the job. Capture both before changing the workflow.

If a matching device is listed but the test still fails, stop treating it as a destination mismatch. Record the device identifier and status from the job’s device list, then compare those details with the destination passed to xcodebuild. Preserve the job log and test result bundle so the failure can be reproduced. A Simulator that is selected but does not boot belongs to a launch or test-execution investigation, not a destination-name fix.

Use the evidence to choose the next action

The table below maps the evidence you collect to a bounded next step. It avoids treating every “no destination” message as a missing Xcode installation.

Evidence in the failing job Likely layer Next action
Scheme output has no compatible iOS Simulator destination Scheme, target, or destination filter Check target platform and correct the destination arguments
Requested OS is absent from simctl list runtimes Runtime availability Confirm the image inventory; decide whether supported component installation is suitable
Runtime exists, but the requested device is absent Device availability or name mismatch Select a listed device or use an image that provides the required device
xcodebuild -version or selected path differs from expectation Active toolchain Correct the selected developer directory or explicit toolchain path
Destination is selected, then Simulator boot or tests fail Launch or test execution Preserve logs and results; diagnose boot and test behavior separately

For a controlled retest, keep the commit, scheme, test command, and requested destination fixed. Record the runner label and the image and toolchain details from the same run. Then compare the build result, destination selection, Simulator launch, and test result independently. A green build alone does not prove that the Simulator tests ran.

What should you check first when xcodebuild reports no matching destination?
Check the actual job’s active Xcode and -showdestinations output, then compare the requested platform, device, and OS filter with that output. If they do not match, inspect the scheme and target before changing or installing components.

Apply a repeatable acceptance check

Use this checklist on the failing workflow before deciding that the hosted image itself is unsuitable:

  • [ ] Open the failed job log and identify the first failing command and step.
  • [ ] Record the runner label and the image details reported by that job.
  • [ ] Record xcode-select -p, xcodebuild -version, and xcrun --find xcodebuild.
  • [ ] Run xcodebuild -showdestinations for the exact scheme used by the test job.
  • [ ] Run xcrun simctl list runtimes and xcrun simctl list devices available in that job.
  • [ ] Compare the requested destination with the runtime and device entries actually printed.
  • [ ] Confirm the scheme and test target support the requested platform.
  • [ ] Repeat with the same commit and command, preserving the job log and test results.

The current GitHub image README is useful for planning, but it is not a promise that every later run will have an unchanged inventory. Rerun the checks after an image update or when the failure first appears. For teams that need a consistent execution environment, an independent Mac can make the toolchain and diagnostic state easier to control; it does not remove the need to pin and record project inputs.

Route What it helps you control Main trade-off
GitHub-hosted xcode-27 runner The workflow requests a published runner image and can collect job-level evidence Image contents change; a required runtime or device may not be available on a particular image
Dedicated remote Mac for a test job You can inspect and maintain the selected host’s Xcode and Simulator setup You own environment preparation, access controls, and upkeep; it is not automatically a replacement for hosted CI
Local Mac reproduction Useful for checking project settings and reproducing a known toolchain state It may not match the hosted runner’s image, permissions, or environment

Move a specific test job only when the evidence points to a real host constraint: the needed runtime or device cannot be supplied suitably on the hosted image, or the team needs a controlled environment to reproduce and maintain that test. Keep other workflow jobs on their existing runners if they do not require the same macOS conditions.

Retest outcome Decision
Build fails before destination selection Fix the build or toolchain issue first; do not migrate a Simulator job based on a destination diagnosis
Destination is absent because the workflow requests the wrong scheme, platform, or device Correct the project or workflow input and retest on the current runner
Runtime or device is unavailable and an installation step is unsuitable or unreliable Evaluate a dedicated Mac for that test job
Destination is selected but Simulator boot or tests fail Investigate launch and test execution; do not label it a destination-matching failure
Same commit and command pass with recorded image and toolchain evidence Keep the workflow and monitor subsequent image changes

When should an Xcode 27 Simulator job move to a remote Mac?
Move it only after you have confirmed the active toolchain and destination inputs, and the required runtime or host conditions still cannot be met reliably on the hosted runner. Simulator acceptance also does not replace real-device testing where your release requirements call for physical-device validation.

For a fixed macOS test environment, compare the maintenance responsibilities with the task’s actual needs before moving the job. A remote Mac is less suitable if you need a long-lived, fully managed fleet without owning environment upkeep, or if the test depends on physical devices and interfaces that the chosen host does not provide. If a separate host fits your workflow, review MACCOME’s remote Mac options and assess the Mac mini environment against the exact Xcode, runtime, access, and persistence requirements you recorded. Use it to reproduce and run the test that needs controlled macOS conditions, while keeping the remaining CI jobs on the runners that already meet their requirements.