Which Simulator Runtimes Ship on macOS Runners?

The macOS 26 image ships the iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 simulator runtimes alongside Xcode 27.0 (build 27A5194q), and it also carries every runtime already present in the upstream GitHub macOS 26 arm64 image it is built from. The macOS 15 and macOS 14 images carry the runtimes that shipped with their own Xcode versions, so the set a test job sees is decided by the image label in runs-on rather than by anything in the repository.

This page maps the runtimes to each macOS label, gives the command that prints the inventory from inside a job, and prices what an in-job runtime download adds to a run.

Answer

A simulator runtime travels with the toolchain release that bundles it, so the question of which runtimes a runner carries reduces to which macOS image the label selects. WarpBuild provides Linux x64, Linux ARM64, macOS, and Windows runners, and the macOS fleet registers five labels across three images, listed in the cloud runners documentation and re-checked on 2026-08-13.

Two facts about that first row are worth stating plainly. Xcode 27.0 is a WarpBuild addition on top of the upstream GitHub macOS 26 image while GitHub's upstream macOS 27 runner image is in beta, and a dedicated macOS 27 image follows once that image is released. The four 27.0 runtimes are the ones that come with Xcode 27.0, so a job on either macOS 26 label can build against the 27.0 SDKs and boot a 27.0 simulator with no download step in the workflow.

For macOS 15 and macOS 14, the upstream image readmes are the authority, because GitHub rebuilds those images on its own cadence and the bundled runtime versions move with the Xcode versions in each rebuild. The WarpBuild preinstalled software documentation links the readme for each image and is the place to start when a version question comes up mid-incident. macOS 13 runners were removed on June 8, 2026, so no runtime answer exists for that image any more.

Detail

Printing the inventory from inside the job

One command answers the question on the machine that is about to run the tests:

      - name: Record the simulator runtimes this runner carries
        run: xcrun simctl list runtimes

Each row prints the platform, the marketing version, the build number, a runtime identifier shaped like com.apple.CoreSimulator.SimRuntime.iOS-27-0, and an availability field that says whether the runtime is usable. The identifier is the stable handle for xcrun simctl create when a job builds a device explicitly. Simulator runtime covers the fields and the device-type pairing in full.

Keeping that step in the workflow costs a second and turns an image update into a visible log diff instead of a test suite that quietly changes what it targets.

When a destination names a runtime the image does not carry

xcodebuild resolves the destination specifier before it compiles anything. A destination naming a runtime the machine lacks fails at that resolution step with an error that no destination matches the specifier, followed by a list of the destinations it did find. The suite never runs, and the failure arrives buried in build output rather than as a clear message about a missing runtime.

Writing OS=latest produces the other failure mode. It resolves to the newest runtime installed on that machine, so an image update that adds a runtime retargets the whole suite with no commit. Snapshot tests recorded against the older guest system start failing, and tests that wait on permission alerts start hanging. A cheap guard makes both cases loud:

      - name: Fail early when the pinned runtime is missing
        env:
          SIM_RUNTIME: "27.0"
        run: |
          xcrun simctl list runtimes | grep -q "iOS ${SIM_RUNTIME}" || {
            echo "iOS ${SIM_RUNTIME} simulator runtime is not installed on this image"
            exit 1
          }

The iOS simulator tests guide wires this into a full xcodebuild test job with result bundles.

What adding a runtime at job time costs

A runtime the image does not carry can be fetched inside the job with sudo xcodebuild -downloadPlatform iOS, or xcodebuild -downloadAllPlatforms for the full set. Runtimes are multi-gigabyte downloads, so that step adds transfer minutes to every run of the job and competes for disk on a runner whose storage is ephemeral and deleted when the runner terminates.

The arithmetic is per minute of added download time, at the rates on the pricing page checked on 2026-08-13. The monthly column assumes 40 pull request builds per weekday across 22 weekdays, which is 880 jobs.

A four-minute download on the 6 vCPU shape is therefore $281.60 a month on that workload, which is the number to weigh against pinning the job to an image that already carries the runtime. Disk is the second constraint: the 6 vCPU labels carry a 120GB SSD and the 12 vCPU labels carry 270GB, so a job that needs several runtimes resident at once belongs on the larger shape.

The macOS runner catalog carries the sizes and rates for every label, and simulator runtimes on WarpBuild macOS runners goes deeper on the per-image sets.

Keeping the set stable

Two habits keep the answer stable over time. Pin the image label rather than the latest alias, since warp-macos-latest-arm64-6x points at warp-macos-15-arm64-6x and moves when that alias moves. Pin the runtime version in one environment variable and reference it from every destination, so the whole matrix moves in a single commit.

Snapshot runners and remote Docker builders sit on the Linux side of the WarpBuild product surface, which also includes CI observability, an MCP server, and the Action Debugger. macOS runners do not support nested virtualization and cannot run Docker, so simulator work stays on the macOS labels and container builds go elsewhere.

Related Questions

Which simulator runtimes do WarpBuild macOS runners carry?

The macOS 26 labels warp-macos-26-arm64-6x and warp-macos-26-arm64-12x carry the iOS 27.0, tvOS 27.0, watchOS 27.0, and visionOS 27.0 runtimes bundled with Xcode 27.0 (build 27A5194q), plus every runtime already present in the upstream GitHub macOS 26 arm64 image. The macOS 15 and macOS 14 labels carry the runtimes bundled with the Xcode versions in their own upstream images. The macOS runner catalog lists all five labels with their sizes and rates.

How do I check which simulator runtimes a runner has before the tests run?

Run xcrun simctl list runtimes as a step in the job. Each row prints the platform, the marketing version, the build number, a runtime identifier, and an availability field, so the inventory lands in the job log and an image change shows up as a log diff. Simulator runtime explains the fields and how a runtime pairs with a device type.

What happens when a destination names a runtime the image does not carry?

The job fails at destination resolution, before any compilation, with an error that no destination matches the specifier. A destination written with OS=latest behaves differently and resolves to the newest runtime on the machine, which silently retargets the suite after an image update. The iOS simulator tests guide shows the guard step that turns both cases into a clear failure in seconds.

What does downloading a simulator runtime inside a job cost?

Each added download minute costs $0.08 per job on the 6 vCPU macOS labels and $0.16 per job on the 12 vCPU labels, from the pricing page checked on 2026-08-13, and multi-gigabyte runtimes also compete for the 120GB SSD on the 6 vCPU shape. Simulator runtimes on WarpBuild macOS runners lists which image already carries the runtime a matrix needs.