macOS 14 runners are retiring: choose architecture and Xcode before changing CI

The deadline is November 2; interruptions come sooner

GitHub's October 1 announcement schedules the macOS 14 runner image's retirement for November 2, 2026. This is an approaching operational deadline, not a new announcement. It affects macos-14, macos-14-large and macos-14-xlarge. GitHub does not specify an exact retirement time or timezone. [1]

Before retirement, GitHub says jobs using macOS 14 will temporarily fail during scheduled brownouts. The remaining windows as of October 15 are below. These are targeted runner interruptions, not a claim that GitHub as a whole will be unavailable. GitHub also says capacity may be reduced and queues could lengthen; it reports no measured delay. [1]

The October 5 and October 12 windows have already passed. Avoid treating a retry on the retiring label as the migration plan: another attempt does not remove the next brownout or the retirement deadline.

Preserve the host requirement, not the label's appearance

The retiring labels do not all describe the same host. GitHub's runner-image map identifies macos-14-large as Intel/x64 and macos-14 plus macos-14-xlarge as arm64. A blanket move to macos-latest can therefore change architecture for an Intel job. The architecture of the machine running the build is a separate requirement from the architecture of the artifact it produces. [2]

Runner size is another choice. GitHub lists larger Intel runners with 12 CPUs and 30 GB RAM, versus larger arm64 runners with 5 CPUs and 14 GB RAM. The names large and xlarge are not a like-for-like performance ranking. Moving from a larger runner to a standard one also changes resources; check account access and approved billing before selecting a larger runner. These are documented specifications, not benchmark results. [3][4]

GitHub recommends arm64 replacements in the retirement announcement, but that is not a compatibility verdict for your dependencies. GitHub says its own actions support arm64 while community actions may not. Its references also document no static UUID/UDID on arm64 runners; if a signing or testing workflow requires a static device identifier, Intel is a documented option. This does not mean arm64 cannot sign builds. [1][3][4]

Use an explicit OS label for the trial. The announcement and image repository associate latest aliases with macOS 26, while the captured larger-runner table still marks macOS 15 large/xlarge as latest. Those references disagree. Do not assume a universal alias mapping: inspect the actual image information in the run's Set up job log. [1][2][4]

A supported OS may still lack the Xcode your build needs

The software inventories provide a concrete reason to check before replacing a label. At the pinned runner-images revision linked below, both macOS 15 inventories list Xcode 16.4 as the default; both macOS 26 inventories list Xcode 26.6 as the default and do not list Xcode 16.4. The macOS 15 inventories also contain newer Xcode versions. Choose the required Xcode deliberately rather than assuming the default matches your build. [5][6][7][8]

Check the SDK and simulator entries associated with that Xcode, not only its version number. For example, the pinned Intel macOS 15 inventory associates Xcode 16.4 with the iOS 18.5 SDK. A required SDK or test destination can rule out a candidate that otherwise has the right host architecture. [7]

These are repository snapshots, not evidence of the image assigned to your next job. GitHub typically updates image software weekly, so macos-15 pins an OS choice, not every installed tool. Verify the image and selected tools inside the trial run. [2]

Hypothetical example: Intel tooling plus Xcode 16.4

Suppose a team uses macos-14-large because a build dependency requires an Intel host, and its release build requires Xcode 16.4. This is a hypothetical decision example; no migration job was run.

macos-15-large is a candidate: the documented host class remains larger Intel, and the pinned macOS 15 Intel inventory lists Xcode 16.4. macos-26-large preserves the host class but does not list that Xcode version in this snapshot. macos-15-xlarge changes the host to arm64. The next action is to trial macos-15-large with Xcode 16.4 explicitly selected—not to declare the workflow compatible. [2][4][7][8]

If that trial fails, use the actual failure to revise the dependency, tool selection or candidate. If the team later validates arm64-compatible tooling, arm64 can become a separate candidate. Neither conclusion follows from changing runs-on alone.

Make the production edit depend on a real build

For an agent-assisted migration, separate finding labels and proposing a change from approving it. The following is a proposed validation process, not a tested procedure for your repository.

• Find the effective label. Inspect runs-on values, matrix entries, reusable workflow inputs and recent job logs for all three retiring labels. A literal search alone can miss a label supplied indirectly.
• Record the requirements before selecting a replacement: host architecture, runner resources, chosen Xcode, SDKs, simulator/test destinations, native dependencies and actions, and any signing or static-UDID requirement.
• Run the candidate in a nonproduction branch or validation workflow using the real dependency resolution and representative build/test target. Where signing is required, use the team's approved validation path; do not expose credentials to an agent or enable production publishing just to test the runner.
• Inspect Set up job for the actual image identity. Confirm host architecture and selected tools, then examine the build, required tests, signing result where applicable, and expected artifact architecture. A successful version printout or started job is not an accepted build.
• Approve the production change only when that evidence satisfies the team's existing build and release criteria. If it fails, fix the specific incompatibility and rerun the representative job before relying on the new label.

The useful outcome is a supported runner choice backed by a passing workload, not a clean search-and-replace diff. Schedule that validation before the remaining brownouts; do not wait for November 2 to discover that the replacement changed your host or toolchain.