When Will Rosetta 2 Stop Being Supported? 2026 Enterprise Mac CI Migration Checklist

The first management error is treating three different compatibility questions as one:

• An Intel Mac running an Intel-only macOS application.
• An Apple Silicon Mac launching an Intel application through Rosetta.
• An Intel binary running inside a Linux virtual machine on Apple Silicon.

These are not interchangeable. Rosetta is a translation environment for running Intel Mac applications on Apple Silicon. Apple documents Linux virtual machine support separately, and that path does not create a general promise that every Intel macOS tool will work in every CI environment. Review Apple’s Linux VM binary guidance before classifying a Linux-based build step as equivalent to a macOS Rosetta workload.

Apple has confirmed the important enterprise boundary: macOS 27 is the final major macOS release with general Rosetta support for Intel-only Mac applications. Apple also states that macOS 26.4 and later may show migration prompts. The public macOS 27.0 Release Candidate was published on September 9, 2026, while the public final release had not yet been published on September 10, 2026. Do not infer the final behavior of macOS 28 from rumors or test builds.

The operational conclusion is narrower and more useful:

• Do not shut down all compatibility nodes today.
• Do not approve new permanent Rosetta dependencies.
• Do not upgrade production Mac CI merely because a sample project opens.
• Do establish an exit date for every compatibility task.
• Do require native arm64 evidence for every production release path.

An Apple Silicon machine can therefore remain operational while still being a migration risk. The hardware may be ready. The software chain may not be.

A Rosetta check that only inspects the main build application is incomplete. The failure may sit in a child process launched by a script, a package manager, an installer hook, or a CI agent.

Build an asset record for each component with these fields:

• Component name and installed path.
• Detected architecture: arm64, x86_64, or universal.
• Calling job, repository, and build stage.
• Runtime owner and escalation contact.
• Replacement version or rebuild plan.
• Production impact if unavailable.
• Validation project and evidence location.
• Exception expiry date.
• Required node pool.

The inventory must cover:

• CLI tools and self-hosted runners.
• Package manager binaries and cached package directories.
• Shell scripts that launch architecture-specific helpers.
• Python, Ruby, Node.js, or other interpreter environments.
• LaunchAgent and daemon definitions.
• CI agents, plugins, and credential helpers.
• Dynamic libraries and compiler toolchains.
• Installer preinstall and postinstall scripts.
• Internal binaries and command-line wrappers.
• Signing, notarization, Keychain, and provisioning helpers.
• Build service plugins that load native libraries.

Use architecture inspection as evidence, not as a substitute for a functional test. A minimal local review can start with:

file /path/to/tool
lipo -info /path/to/tool
uname -m
ps -axo pid,comm

file shows the file type reported by the system. lipo -info helps identify the architecture slices of a Mach-O binary. uname -m describes the current shell environment, not necessarily the architecture of every child process. A process list can reveal the executable that the CI job actually launched.

For a running process, record the executable path and inspect that file separately. A native shell can still start an Intel-only helper. Conversely, a universal binary may launch an arm64 slice while a plugin loaded later remains x86_64.

Do not mark a task migrated because an installer completed successfully. The real test is whether the project compiles, tests, archives, signs, notarizes, uploads, and recovers without the translated dependency.

Responsibility and handoff record

This ownership model prevents a common handoff failure: the platform team reports that the node is arm64, while the toolchain team has not proved that the release job is native.

The question is not whether macOS 27 can still run an Intel application. The question is whether your production pipeline depends on that behavior at a point you have not documented.

Start with the build graph, not the machine list. For each job, identify every process launched directly and indirectly. Review shell scripts, package installation steps, environment initialization, plugin discovery, and post-build upload commands.

Check these locations and behaviors:

• PATH order. An arm64 host may select an older Intel tool from a legacy directory.
• Package manager prefixes. Separate native and translated installations can coexist.
• CI agent bootstrap scripts. The agent itself may be native while a helper remains Intel-only.
• Plugin folders. A universal host application can load an architecture-specific plugin.
• Dynamic library search paths. A binary may start but fail when a library is loaded.
• Installer hooks. A package may install correctly but execute an Intel postinstall script.
• Cache keys. A cache produced by an Intel process may be reused by an arm64 process.
• Shell wrappers. A script may force an architecture through an explicit launcher.
• Credential and signing helpers. These often run late in the pipeline and escape basic compile tests.
• Launch services and background agents. They may start only after reboot or user login.

A useful asset status is not simply “compatible” or “incompatible.” Use these categories:

• Native verified: the process and its critical dependencies ran as arm64 in a representative job.
• Universal verified: both slices are present, and the required slice passed signing and runtime tests.
• Translated observed: the task still launches through Rosetta.
• Unknown: architecture is not yet proven in the production path.
• Blocked: the component fails, requires unsafe settings, or has no supported replacement.
• Exception: temporary compatibility is approved with an owner and exit date.

Record the command output, job URL, commit identifier, artifact hash, and log timestamp. This turns a migration discussion into an auditable change record.

There are three legitimate responses to an Intel dependency.

Replace it. Use this when the vendor provides a supported arm64 build and the tool’s behavior is stable in your project. Pin the version and update the image definition. Do not silently use a developer workstation installation.

Rebuild it. Use this for internal tools or source-available components. Build an arm64 artifact or a Universal Binary. Apple’s Universal Binary build guidance explains the platform requirements, but your acceptance test still needs to cover the actual CI workflow.

Isolate it temporarily. Use this only when the component is closed-source, contract-bound, or not yet replaceable. Place it in the compatibility pool. Give it an owner, a documented business reason, a review date, and an exit condition.

A Universal Binary is not automatically migration-complete. Both architecture slices must pass:

• Code signing.
• Notarization or internal distribution checks.
• Plugin loading.
• Keychain access.
• Provisioning and certificate selection.
• Reboot and unattended launch.
• Artifact upload.
• Runtime behavior in the target project.

Apple’s Apple Silicon porting documentation is useful for developers deciding what to rebuild. It does not replace project-level verification. A compiler can produce an arm64 binary while a test fixture, plugin, or packaging helper still launches as x86_64.

Yes, if a production task has a confirmed Intel-only dependency and no tested replacement. No, if the compatibility pool is being kept merely because nobody has inspected the dependency chain.

Use two explicitly separated pools:

• Native pool: Apple Silicon nodes, native toolchain, native cache namespace, production migration target.
• Compatibility pool: Apple Silicon nodes allowed to run approved translated workloads, separate cache namespace, restricted job labels, documented exit dates.

Do not let routing depend on an implicit environment variable. Use visible labels or queues such as macos-arm64-native and macos-rosetta-exception. The job definition should state why it requires the compatibility pool.

The following comparison helps determine the correct operating model:

The compatibility pool should not receive new permanent dependencies. If a new tool works only through Rosetta, require an exception review before merging it into the CI image.

Select representative jobs rather than the easiest jobs. Include at least one pull request build, a test-heavy workflow, an archive, a release upload, and a recovery run. The exact job set should reflect your organization’s release risk.

Run the same commit through the native and compatibility paths where the comparison is meaningful. Keep these variables visible:

• Source revision.
• Xcode and SDK selection.
• Dependency lockfiles.
• Signing identities and provisioning profiles.
• Environment variables.
• Cache state.
• Node image identifier.
• Architecture of every critical process.
• Artifact hash.
• Test result.
• Queue and retry behavior.
• Recovery result after restart.

Do not publish unsupported performance claims from a short sample. Queue time, build duration, and node capacity must come from your own enterprise records or a clearly labeled CALMVPS measurement. This runbook does not invent throughput numbers.

Compare outcomes in four groups:

Functional correctness. Do the tests pass? Does the archive launch? Are symbols, resources, and embedded frameworks present?

Artifact equivalence. Are differences expected and documented? Compare bundle contents, signing status, architecture slices, metadata, and hashes where deterministic output is expected.

Release security. Does the native path access Keychain and signing services without an interactive session? Does notarization or internal distribution complete?

Operational recovery. After a reboot or agent restart, does the node reconnect, retrieve credentials according to policy, and accept a job without a person opening a desktop session?

A job that succeeds only after a developer logs in is not an unattended CI success. A job that compiles but fails during notarization is not a release-ready migration.

Apple’s Xcode 27 Release Notes should be reviewed alongside the macOS notes when you select the target image. Keep Xcode, SDK, signing tools, and third-party plugins in the same validation record.

Rosetta migration can expose security weaknesses that ordinary build checks miss. Review the full release path before approving a node for production.

Check the following items:

• Keychain access from a non-interactive CI session.
• Code signing with the intended identity.
• Provisioning profile selection.
• Notarization or internal distribution validation.
• Internal plugins and native extensions.
• Daemons and LaunchAgent behavior after reboot.
• File permissions on certificates and build credentials.
• Recovery after an interrupted job.
• Artifact retention and log access.
• Removal of obsolete translated binaries from the image.

Any component that requires lowering system security settings should be blocked or placed on a time-limited exception list. Do not convert a compatibility problem into a permanent control failure.

Define rollback before the upgrade. A rollback plan should state:

• Which jobs return to the compatibility pool.
• Which image or snapshot is restored.
• How cache contamination is prevented.
• Who can approve the rollback.
• Which failed evidence triggers it.
• How the incident is recorded.
• When the native migration is retried.

Rollback is not a reason to avoid migration. It is the control that lets you test the migration without risking an unplanned release outage.

Do not estimate Mac capacity from developer headcount. Model the work that actually reaches CI.

Use these variables:

• Pending native migration workload.
• Native node effective capacity from enterprise records.
• Release peak demand.
• Required redundancy.
• Compatibility workload remaining.
• Compatibility pool exit date.
• Expected retry and recovery load.
• Queue policy between pull requests and releases.

A basic planning expression is:

Required native capacity = peak native workload + migration workload + recovery reserve

Keep the variables separate in your planning sheet. If you hide migration workload inside ordinary demand, you may underbuy capacity during the dual-run period.

Choose the operating model using this matrix:

If the current Apple Silicon fleet cannot support dual-run demand, compare three real options: add owned nodes, rent remote Mac capacity for the migration window, or operate a hybrid pool. Do not assume rental is always cheaper. Do not assume purchase is always cheaper. The correct answer depends on duration, utilization, procurement lead time, redundancy, maintenance ownership, and release peaks.

For a temporary isolated test pool, document access control, root privileges, network policy, credential handling, data retention, and teardown. CALMVPS’s remote Mac ordering page can be used to review a short-term Mac environment after your dependency inventory defines the required test conditions. If you need to compare recurring plans, use the CALMVPS pricing page as a commercial input, not as a substitute for your internal TCO model.

IT infrastructure owner

• [ ] Confirm the target macOS 27 image and its release-note status.
• [ ] Record every Apple Silicon node and its recovery method.
• [ ] Separate native and compatibility labels.
• [ ] Create independent cache and workspace policies.
• [ ] Test reboot, agent reconnect, and unattended job pickup.
• [ ] Confirm who can approve an exception and who owns its removal.

Toolchain owner

• [ ] Scan executables, dynamic libraries, plugins, interpreters, and installers.
• [ ] Mark each item as native, universal, translated, unknown, blocked, or exception.
• [ ] Replace vendor tools with supported arm64 builds where available.
• [ ] Rebuild internal tools as arm64 or Universal Binary where practical.
• [ ] Test real projects, not only installation commands.
• [ ] Record artifact, signing, and notarization evidence.

CI platform owner

• [ ] Route native jobs to the native pool explicitly.
• [ ] Route approved exceptions to the compatibility pool explicitly.
• [ ] Prevent cache reuse across architecture pools.
• [ ] Dual-run representative pull request, test, archive, and release jobs.
• [ ] Compare artifacts, logs, queue behavior, and recovery.
• [ ] Reject new permanent x86_64 dependencies.

Security and release owner

• [ ] Validate Keychain access without an interactive desktop session.
• [ ] Validate signing and provisioning on both relevant paths.
• [ ] Check plugins and daemons after reboot.
• [ ] Record hashes, logs, approvals, and failed attempts.
• [ ] Block any workaround that weakens required system security.
• [ ] Define rollback triggers before production upgrade.

Procurement owner

• [ ] Use workload and peak release demand rather than developer count.
• [ ] Include dual-run demand in the capacity model.
• [ ] Set a compatibility pool exit date.
• [ ] Compare owned nodes, remote Mac rental, and hybrid capacity.
• [ ] Require supplier evidence for access, isolation, recovery, and delivery.
• [ ] Approve long-term capacity only after native migration evidence exists.

Do not wait for Rosetta to fail visibly in production. macOS 27 may still run an Intel-only application, but that remaining compatibility is the deadline pressure, not the safety argument. Freeze new x86_64 dependencies, prove native execution on representative release paths, and keep exceptions isolated with owners and exit dates.

If your current approach is a fixed Intel-era toolchain, it leaves you with hidden translation dependencies, unclear ownership, cache contamination risk, and an upgrade decision tied to emergency testing. Buying every Apple Silicon node immediately can create excess capacity during the migration peak. A better short-term option is often a small, isolated Apple Silicon remote Mac pool for dual-run validation, followed by a purchase or rental decision based on measured workload and recovery evidence.

Once your inventory identifies the required architecture, signing controls, and test jobs, you can use CALMVPS to create a controlled remote Mac trial. Validate the real pipeline first. Then decide whether the resulting evidence supports permanent owned capacity, continuing rental, or a hybrid node pool.