GitHub Actions Retires the macOS 14 Runner Image on November 2, 2026: What to Change
GitHub will retire the macOS 14 runner image for GitHub Actions on November 2, 2026. Any automated build that asks for the labels macos-14, macos-14-large or macos-14-xlarge will stop working on that date, and it will be interrupted earlier during scheduled brownouts that began on October 5, 2026. For most businesses this affects the pipeline that builds, tests and ships an iPhone or Mac app.
GitHub published the notice on October 1, 2026 in its changelog: GitHub Actions: macOS 14 runner image retirement. The dates and labels below were checked against GitHub's pages on October 6, 2026.
The fix is usually a small change, but it has to be tested, because a newer macOS image carries different versions of Apple's build tools. If your app was built some time ago and nobody is actively looking after its build setup, this is the kind of job covered by ongoing iPhone app development and maintenance work.
What is GitHub retiring, and when?
GitHub is retiring the macOS 14 image used by its hosted runners, with retirement on November 2, 2026. A runner is the temporary machine that GitHub starts to carry out an automated job such as compiling an app or running tests. The image is the operating system and preinstalled software on that machine. GitHub Actions is the automation service that runs these jobs from instructions stored in your code repository.
The changelog names three affected labels: macos-14, macos-14-large and macos-14-xlarge. A label is the line in a workflow file that says which kind of machine a job should run on.
The retirement follows GitHub's published policy. The actions/runner-images repository states that GitHub supports at most two generally available images and one beta image at a time, and begins deprecating the oldest once the newest reaches general availability. As of October 6, 2026 that repository marks both macOS 14 images as deprecated and lists macOS 15 and macOS 26 as the current ones.
Which workflows are affected?
Only workflows that name one of the three macOS 14 labels explicitly are affected. Jobs that run on Linux or Windows runners are not part of this change. Jobs that use the macos-latest label are also not affected by this retirement, because the runner-images repository shows macos-latest already pointing to macOS 26 on arm64.
The usual reasons a project pins macos-14 are an older Xcode version that the app was last built with, a dependency that had not been tested on newer macOS, or simply that the workflow was written in 2024 or 2025 and never revisited. Projects that commonly have macOS jobs include native iOS and macOS apps, Flutter and React Native apps that produce an iOS build, and libraries that test on Apple platforms.
Self-hosted runners, meaning Macs that your own team operates and connects to GitHub, are not GitHub-hosted images. The changelog entry is about the image GitHub provides.
What are the brownouts, and when do they happen?
Brownouts are planned, temporary interruptions that GitHub schedules before the retirement so that teams notice the change before it becomes permanent. During a brownout window, expect jobs that request a macOS 14 label not to run successfully.
The changelog lists eight windows, each running from 14:00 UTC until 00:00 UTC the following day, starting on these dates in October 2026: October 5, October 12, October 16, October 19, October 23, October 26, October 29 and October 30. The first window has already passed. In US Eastern time the windows run from 10:00 a.m. to 8:00 p.m.; in UK time they run from 3:00 p.m. to 1:00 a.m. until the clocks go back on October 25, 2026, and from 2:00 p.m. to midnight after that.
The practical risk is a release or an urgent fix planned for one of those afternoons. A build that worked on Thursday can fail on Friday for no reason connected to your code.
What should replace macos-14?
GitHub recommends moving to a macOS 15 or macOS 26 arm64 label. The changelog lists these replacements:
- macos-latest, which currently means macos-26
- macos-15
- macos-latest-xlarge, which currently means macos-26-xlarge
- macos-15-xlarge
A note on Intel builds
The recommended replacements are all arm64, which is Apple silicon. The runner-images repository lists macos-14-large as an x64 (Intel) image. If your project uses that label because it needs an Intel machine, the same repository lists Intel labels for the newer versions, including macos-15-intel and macos-26-intel. Ask your developer to confirm which one fits before switching.
Why it is more than a one-line edit
Changing the label changes the tools on the machine. GitHub's runner-images repository says that only one major version of Xcode is supported per macOS version, so a move from macOS 14 to macOS 15 or 26 means building with a newer Xcode. Older projects can hit compile warnings that have become errors, outdated dependencies, or signing steps that need adjusting. Choosing macos-15 is the smaller jump; choosing macos-26 or macos-latest postpones the next migration for longer. GitHub's documentation on GitHub-hosted runners lists the labels and machine sizes currently on offer.
Why does this matter to a business owner who does not write code?
It matters because a broken build pipeline blocks every release, including urgent ones. If the pipeline fails on November 2, your team cannot ship a bug fix, a security patch or a store-mandated update until someone repairs it, and that repair then happens under pressure instead of on a quiet day.
Apps that are finished and rarely updated are the most exposed. Nobody is watching their builds, so the first sign of trouble tends to be the day a fix is needed. Our article on software maintenance and support explains why this sort of upkeep exists even when no new features are planned.
What should a business do now?
Ask whoever maintains your app to check for the macOS 14 labels this week and to move the build before November 2, 2026. A sensible order of work:
- Search every repository's workflow files for macos-14, including the large and xlarge variants.
- Change the label on a separate branch to macos-15 or macos-26 and run the full build and test suite.
- Fix whatever the newer Xcode rejects, then produce a test build and install it on a real device.
- Merge the change before the next brownout window, and avoid scheduling releases inside the remaining windows until it is merged.
- Note the current image policy so the next retirement is planned for, not discovered.
If your builds run on another service or on your own Macs, this notice does not apply directly, but the same question is worth asking of that setup: which macOS and Xcode version does it build with, and when does support for it end?
Quick answers
When does GitHub retire the macOS 14 runner image?
GitHub retires the macOS 14 runner image for GitHub Actions on November 2, 2026. The notice was published in the GitHub changelog on October 1, 2026.
Which GitHub Actions labels stop working?
The affected labels are macos-14, macos-14-large and macos-14-xlarge. Workflows that request any of them need to be updated before November 2, 2026.
What should I use instead of macos-14 in GitHub Actions?
GitHub recommends macos-15 or macos-latest (currently macos-26) for standard runners, and macos-15-xlarge or macos-latest-xlarge (currently macos-26-xlarge) for larger ones. All four are arm64 images.
Why did my macos-14 build fail in October 2026?
GitHub scheduled brownouts for the macOS 14 image on October 5, 12, 16, 19, 23, 26, 29 and 30, 2026, each from 14:00 UTC to 00:00 UTC the next day. A job that requests a macOS 14 label during one of those windows can fail even though the code has not changed.
Is macos-latest affected by the macOS 14 retirement?
No. As of October 6, 2026, GitHub's runner-images repository shows the macos-latest label pointing to macOS 26 on arm64, so it does not use the macOS 14 image.
Conclusion
The macOS 14 retirement on November 2, 2026 is routine housekeeping by GitHub, but it has a hard date and a series of brownouts before it. The work is a label change plus whatever the newer Xcode asks of your project, and it is far easier to do in a calm week than on the day a release is due. Check for the three labels, test on macOS 15 or 26, and merge before the end of October.
If your app's build setup has no owner at the moment, you can contact Entrant Technologies and we will take a look.