What Xcode Versions Are on GitHub Actions Runners?

The Xcode versions a GitHub Actions job can use come from the macOS image the runner boots, so the runs-on label picks the toolchain set. On WarpBuild macOS runners, the macOS 26 labels ship Xcode 27.0 (build 27A5194q) with the iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 simulator runtimes on top of the Xcode versions already in the upstream GitHub macOS 26 image (macOS 26 tooling, checked on 2026-08-13).

Answer

Every WarpBuild macOS image is built from the matching upstream GitHub runner image and carries the same tooling (preinstalled software documentation), so the Xcode list on a given image is the published upstream list for that image, with one addition on macOS 26.

Four simulator runtimes come bundled with the Xcode 27.0 install on macOS 26: iOS 27.0 (24A5355p), tvOS 27.0 (24J5289o), watchOS 27.0 (24R5289n), and visionOS 27.0 (24M5291p) (macOS 26 tooling). A job on either macOS 26 label can compile against the 27.0 SDKs and boot a 27.0 simulator destination with no runtime download step in the workflow.

Xcode 27.0 on macOS 26 is a WarpBuild addition on top of the upstream GitHub macOS 26 image while GitHub's upstream macOS 27 runner image is in beta. A dedicated macOS 27 image follows once that upstream image is released, at which point the Xcode 27.0 bundle path on the macOS 26 image stops being the place to pin, so any workflow that hardcodes it needs one edit.

One label is gone from this list: macOS 13 runners were removed on June 8, 2026 (cloud runners documentation). A workflow that still names a macOS 13 label queues without a match, so move those jobs to macOS 14, macOS 15, or macOS 26.

WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners. The full macOS lineup, with sizes and rates for each of the five labels above, is on the macOS runner hub.

Detail

Exact patch versions live in the image readme

GitHub regenerates the runner image readmes on every image release, so a specific patch version such as 16.2 or 16.4 belongs there rather than on a page that refreshes on a 90 day cadence. The three readme links in the table above are the per-build inventory for each image, and the preinstalled software documentation keeps the readme link for each WarpBuild image in one place.

macOS 14 is the narrowest of the three images. The macos-14-arm64 readme lists the Xcode 15 line with 15.4 as the default, and WarpBuild tracks that image as published. A job that needs Xcode 16 or later moves up an image rather than reaching for a version macOS 14 no longer carries.

Selecting a version inside the job

The label decides which Xcode versions exist on the machine. DEVELOPER_DIR decides which one the build uses.

name: ios-pr
on:
  pull_request:
    branches: [main]

jobs:
  build-and-test:
    runs-on: warp-macos-26-arm64-6x
    env:
      DEVELOPER_DIR: /Applications/Xcode_27.0.app/Contents/Developer
    steps:
      - uses: actions/checkout@v4

      - name: Record the toolchain in the job log
        run: |
          ls -1 /Applications | grep Xcode
          xcodebuild -version
          xcrun simctl list runtimes

      - name: Build and test
        run: |
          xcodebuild test \
            -scheme AppScheme \
            -destination "platform=iOS Simulator,name=iPhone 16 Pro,OS=27.0"

DEVELOPER_DIR is scoped to the job, needs no sudo, and applies to xcodebuild, swift, and every xcrun call in the steps that follow. The ls -1 /Applications | grep Xcode step prints the bundle names the image actually carries, which is the fastest way to confirm a pin before a compile error does it for you.

Two aliases need care in Xcode-sensitive workflows. warp-macos-latest-arm64-6x and warp-macos-latest-arm64-12x resolve to the macOS 15 labels, in sync with GitHub's macos-latest tag, so a job on an alias moves to a different image and a different Xcode set the day the alias moves (cloud runners documentation). Pin the versioned label when the toolchain matters.

What the image choice costs

macOS rates are flat per minute by size and do not vary with the image, so a macOS 26 job and a macOS 14 job at the same vCPU count cost the same.

WarpBuild rates come from the cloud runners documentation and the pricing page. The GitHub list price comes from the GitHub Actions minute multipliers, checked on 2026-08-13. On the matched Apple Silicon pair, $0.080 against $0.102 is $0.022 lower per minute, 22 percent lower list price, on a runner that carries one more vCPU and 8 GB more memory (GitHub pricing, checked 2026-08-13).

Related Questions

Which Xcode version does a WarpBuild macOS runner give me?

The one carried by the image behind the label. macOS 26 labels carry the upstream GitHub macOS 26 Xcode set plus Xcode 27.0 (build 27A5194q) with the iOS, tvOS, watchOS, and visionOS 27.0 simulator runtimes. macOS 15 labels carry the upstream macOS 15 set, and warp-macos-14-arm64-6x carries the Xcode 15 line with 15.4 as the default. The per-image breakdown is on the Xcode image coverage page.

How do I select a specific Xcode version inside a workflow?

Set DEVELOPER_DIR to the Contents/Developer path of the bundle you want, or run sudo xcode-select -s on that path before the build step. Print xcodebuild -version in the same job so the log records the toolchain that compiled the artifact. The Xcode selection answer covers both forms and the failure modes of each.

Is there a macOS 27 runner image?

Not yet. Xcode 27.0 is a WarpBuild addition on top of the upstream GitHub macOS 26 image while the upstream macOS 27 image is in beta, and a dedicated macOS 27 image follows once that image is released.

Pick a label on the macOS runner hub, check the shape against the macOS runner sizes page, and price your own Xcode minutes on the pricing page.