Check labels and arm64 requirements before moving to the GitHub Actions Xcode 27 runner

How do you choose an Xcode 27 image?

The release announcement says this image runs on macOS 27 and includes the Xcode 27 toolchain and Apple SDKs. Xcode-based images are organized around a major Xcode version.

When choosing a runner label, check the required tool version and CPU architecture alongside the operating system. arm64 is the architecture used by Apple Silicon. Executables downloaded for an Intel environment need a separate compatibility check for the new environment.

Do existing macos-latest jobs move automatically?

As checked on October 19, the official image list maps macos-latest to macOS 26 arm64. Xcode 27 has its own labels.

Source: GitHub's runner-images list, checked October 19, 2026. The image targeted by latest can change later.

If you need Xcode 27, inspect the job's runs-on value. The announcement says workflows already using xcode-27 or xcode-27-xlarge during preview do not need a label change for general availability.

Where can you check the default Xcode and SDKs?

The Xcode table in the installed software document lists versions and paths. Image 20261012.0260.1, checked for this article, marks Xcode 27.0 as the default, at /Applications/Xcode_27.app. Xcode 27.1 and 27.2 beta also appear in the table; the full installed list does not indicate which version is selected by default.

The SDK table separates SDKs by Xcode version. For example, the iOS 27.0 SDK is associated with Xcode 27.0. If a build needs a particular SDK, check whether the default Xcode provides it.

Software in generally available images is updated weekly. A runner label does not pin every tool's exact version. Keep the environment details from the run log together with the corresponding image documentation.

What should you compare in an existing build first?

The following steps are suggestions for finding differences between the old and new environments. Recording the current job's environment before changing its runner label makes the comparison easier.

1. Find the target job's runs-on, DEVELOPER_DIR, and Xcode selection steps in .github/workflows. Look for settings that pin an old path.
2. Print uname -m, xcodebuild -version, and xcodebuild -showsdks before the build. Compare architecture, selected Xcode, and SDKs in the logs.
3. Check vendor documentation for arm64 support in downloaded executables and native dependencies. If you reuse a cache, check whether its key distinguishes architectures.
4. Compare the same commit in the existing and new environments, recording failed steps and environment output. This is a suggested check, not a guarantee of project compatibility.

What else should you check before choosing xlarge?

If you are considering xcode-27-xlarge, first check eligibility and billing in the larger runner documentation. Larger runners are available to organizations and enterprises on GitHub Team or Enterprise Cloud. Execution is billed in public repositories too, and included minutes do not apply.

A label's name cannot establish that a build will run faster or cost less. Before running it, check which runners your organization can use and the current billing terms, then record execution time for the job you want to compare. Official sources were checked on October 19, 2026.