The infrastructure underpinning continuous integration and continuous delivery (CI/CD) pipelines is not static. For developers relying on hosted runners, particularly those operating within the Apple ecosystem, the environment undergoes significant, scheduled transformations. As of early 2026, the landscape for macOS-based build agents has shifted dramatically. The macos-latest label, a cornerstone of many workflow definitions, has migrated from macOS 14 to macOS 15, a process that concluded in late 2025. Simultaneously, the platform has introduced macOS 26 as a generally available option, marking a new era of native Apple Silicon support alongside legacy Intel compatibility. These changes are not merely version increments; they represent fundamental shifts in supported toolchains, runtime dependencies, and hardware architectures that demand careful attention from DevOps engineers and software architects.

The Architecture of Hosted Runner Labels

To understand the impact of these updates, one must first understand the mechanism by which GitHub Actions and Azure DevOps allocate resources. The platform utilizes YAML labels to define the environment in which a workflow executes. The -latest suffix, found in labels such as ubuntu-latest, windows-latest, and macos-latest, does not point to a static version. Instead, it is a dynamic alias that always resolves to the newest stable operating system version currently supported by the provider.

This dynamic nature introduces a specific set of operational risks and benefits. The migration of the -latest label to a new operating system version is a gradual process, typically spanning one to two months. This extended timeline is intentional, designed to allow customers to detect regressions, adapt their workflow files, and stabilize their pipelines before the old environment is fully deprecated. However, during this transition window, a single workflow file may execute on different operating system versions across different runs. A pipeline running on August 1st might execute on macOS 14, while the same pipeline running on August 15th might execute on macOS 15, depending on the rollout progress.

To mitigate the unpredictability of dynamic labeling, engineers are advised to pin their workflows to specific versions when stability is paramount. By specifying explicit labels such as macos-14, macos-15, or macos-26 in the YAML configuration, teams can freeze the environment and prevent unexpected breakage caused by underlying OS upgrades.

```yaml

Example of pinning to a specific version to avoid migration issues

jobs:
build:
runs-on: macos-15
steps:
- name: Checkout code
uses: actions/checkout@v4
```

Conversely, those who wish to ride the bleeding edge can utilize beta images. These pre-releases are created when the deployment of a new image begins. Beta images serve a critical function in the platform's quality assurance lifecycle: they allow the provider to collect feedback and identify bugs before the image reaches General Availability (GA). It is crucial to note that workflows running on beta images do not fall under the customer Service Level Agreement (SLA). They are experimental by design, and users are encouraged to submit issues directly to the runner-images repository if they encounter anomalies.

The Migration to macOS 15 as the Latest Default

The most significant recent shift in the macOS runner landscape was the migration of the macos-latest label from macOS 14 to macOS 15. This transition was announced in July 2025 and began on August 4, 2025, with the intention of completion by September 1, 2025. Although internal planning documents suggested a target completion date of August 30, 2025, the public announcement confirmed the window extending into early September. During this period, workflows utilizing macos-latest were gradually switched to the new image. Once a runner instance was migrated, it would no longer execute on macOS 14 for any future runs.

The migration applied not only to the standard runner but also to the larger infrastructure options unique to macOS. The macos-latest-large and macos-latest-xlarge labels were also updated to point to macOS 15 equivalents. These larger runners provide increased compute resources for heavy build tasks, parallel testing, or containerized workflows that require more memory and CPU cores than the standard runner can provide.

The decision to elevate macOS 15 to the default status was driven by a period of rigorous testing and feedback collection. macOS 15 had been available in preview mode for GitHub Actions since September 2024, achieving General Availability for all customers on April 10, 2025. Parallel support in Azure DevOps began in preview mode on March 18, 2025. By the time of the migration in August 2025, the image had matured through the beta phase, addressing major bugs and ensuring that the major software installed on the image was compatible with the underlying OS.

However, this migration introduced significant breaking changes for workflows that depended on specific software versions present in macOS 14. The toolchain differences are substantial and require careful audit.

Software and Toolchain Differences Between macOS 14 and macOS 15

The shift from macOS 14 to macOS 15 is not transparent at the application layer. Developers must account for changes in compilers, runtimes, and dependency managers.

The removal of Mono, NuGet, and Nunit from the macOS 15 images is a notable departure for .NET developers. These tools were previously pre-installed but were removed due to maintenance reasons. Teams relying on these tools must now install them explicitly within their workflows using package managers or scripts. Similarly, the removal of Java 8 from the Intel-based image ensures consistency across architectures, forcing a minimum baseline of Java 11 for Intel builds and Java 21 as the default across the board.

For Android developers, the jump in Android Command Line Tools from version 11 to 16, and Android SDK Build-tools from 33 to 35, reflects the rapid pace of Android toolchain updates. Stale versions were deprecated to reduce the storage footprint and maintenance burden on the runner images.

Xcode Support Policy Changes

Concurrent with the OS migration, GitHub updated its policy regarding Xcode installation on macOS runner images. The platform has always supported bare bones Xcode versions, but the strategy for runtime support—specifically simulators—has tightened. Starting August 11, 2025, the runner images will maintain at most three runtimes (simulators) at any given time. Beta runtimes are no longer guaranteed to be present and are only kept on a best-effort basis.

This policy change forces development teams to be more intentional about their testing strategy. If a workflow requires a specific simulator runtime that is not among the three retained by the image, it must be installed explicitly via the Xcode command line tools or through specific workflow steps. This reduces the baseline size of the runner image and ensures that the most current and stable simulators are available by default, but it shifts the burden of older or experimental runtime management onto the user.

```bash

Example of explicitly installing a specific simulator runtime

xcodebuild -runFirstLaunch
xcrun simctl runtime add https://devimages-cdn.apple.com/downloads/xcode/simulators/...
```

The Retirement of macOS 13

As new versions come online, older versions are retired according to the N-1 OS support policy. This policy dictates that only the latest two versions of an operating system are supported on hosted runners. Following this guideline, the macOS 13 hosted runner image entered its decommissioning phase in late 2025. The process began on October 1, 2025, with the image being fully retired on December 4, 2025.

Teams still relying on macOS 13 were urged to update their workflows to use macos-14 or macos-15. The retirement of macOS 13 underscores the importance of keeping workflows current. While pinning to an older version provides stability, it also creates technical debt that must eventually be addressed when the runner image is removed from the infrastructure entirely.

General Availability of macOS 26

While the migration to macOS 15 stabilized the macos-latest label, the platform simultaneously pushed the boundaries of future support with the General Availability of macOS 26 in February 2026. Previously available in public preview, macOS 26 runners now provide a fully supported environment for building and testing applications with the latest macOS and Xcode tooling.

The most significant aspect of the macOS 26 runner is its hardware architecture. These runners run natively on Apple Silicon (arm64). This represents a major shift in the performance and compatibility profile for CI/CD pipelines. However, GitHub maintains support for Intel (x64) architectures through specific labels, ensuring that legacy workflows are not immediately broken by the transition to ARM.

The available labels for macOS 26 reflect this dual-architecture support and the continued availability of larger runner sizes for GitHub Actions:

• macos-26: Standard macOS runner for arm64.
• macos-26-intel: Standard macOS runner for x64.
• macos-26-large: Large runner for x64.
• macos-26-xlarge: Extra-large runner for arm64.

It is important to note that the -xlarge and -large suffixes are unique to macOS images and are only available for GitHub Actions, not Azure DevOps. This distinction highlights the diverging feature sets between the two platforms even as they share underlying image infrastructure.

The introduction of macOS 26 with native arm64 support offers significant performance benefits for many build tasks, particularly those involving compilation and simulation. However, developers must verify that their toolchains, dependencies, and test suites are compatible with Apple Silicon. Cross-compilation for Intel targets may require Rosetta 2 emulation or specific Intel runner instances (macos-26-intel).

Mitigation and Adaptation Strategies

For organizations navigating these transitions, a proactive approach is essential. The gradual nature of the -latest migration means that failures may appear intermittently. The first line of defense is to identify workflows that are sensitive to OS version changes. If a workflow begins failing after the migration starts, the immediate mitigation is to switch back to the previous version by specifying the explicit label, such as macos-14, in the YAML file.

yaml jobs: build: # Pin to macOS 14 to avoid migration issues during the transition runs-on: macos-14 steps: - name: Build run: make build

Once the workflow is stabilized, engineers should audit the software dependencies. If the workflow relies on Mono, NuGet, or Nunit, these must be added back into the workflow steps using Homebrew or official installers. If the workflow relies on specific Xcode versions or simulator runtimes, explicit installation steps must be added to the workflow to ensure they are present, given the new policy of limiting pre-installed runtimes to three.

Monitoring the actions/runner-images repository is also critical. Pre-releases are created when a new image deployment begins, and converting these to final releases signals the end of the beta period. Subscribing to releases and monitoring issues with the Announcement label provides early warning of upcoming changes, allowing teams to prepare for the next wave of migrations.

Conclusion

The evolution of macOS runners on GitHub Actions and Azure DevOps reflects a broader trend in cloud infrastructure: the push towards newer, more efficient hardware and software stacks, coupled with a disciplined lifecycle management policy. The migration of macos-latest to macOS 15 and the subsequent introduction of macOS 26 demonstrate the platform's commitment to providing access to the latest development tools while maintaining stability for existing workflows.

For developers, this means that macos-latest is no longer a safe default for production-critical pipelines without careful testing. The dynamic nature of the label, combined with significant changes in pre-installed software and hardware architecture, requires explicit version pinning for stable builds and proactive adaptation for those seeking the performance benefits of Apple Silicon and newer Xcode versions. By understanding the N-1 support policy, the Xcode runtime limitations, and the specific toolchain differences between OS versions, engineering teams can maintain robust, reliable CI/CD pipelines amidst constant platform evolution.

Sources

1. GitHub Changelog: Upcoming changes to macOS hosted runners
2. GitHub Changelog: macOS 26 is now generally available for GitHub hosted runners
3. GitHub Actions Runner Images Issue #12520
4. GitHub Actions Runner Images Repository