Start a project

← All posts

Rosetta 2's Final macOS: What Developers Must Audit Now

· Dracode · apple · macos · developer-tools
Close-up photograph of a chip processor with visible circuitry and metal contacts

The Announcement

At WWDC 2026, Apple confirmed that macOS Golden Gate—the upcoming macOS 27 release—will be the final version of macOS to ship Rosetta 2. Starting with macOS 28, expected fall 2027, Intel-compiled apps will not run on Apple Silicon Macs at all.

This closes a transition Apple started in November 2020 when it shipped the first M1 Macs. Six years is a generous runway. The bridge is now ending.

What Rosetta 2 Actually Does

Rosetta 2 is a dynamic binary translator built into macOS. When you launch an Intel-compiled (x86_64) app on an Apple Silicon Mac, macOS silently translates the x86 instructions to ARM64 at runtime. For most productivity apps the overhead was negligible—often a few percent slower than a native build. For compute-heavy tools the gap was more pronounced.

The key word is silently. Millions of Mac users have been running Intel apps on M-series chips for years without realizing it. Removing Rosetta 2 removes that safety net entirely. There is no fallback. An Intel-only binary that hits macOS 28 simply will not launch.

Which Apps and Tools Are Actually at Risk

The obvious category is legacy software that never shipped a universal binary: older design tools, specialized audio plugins, enterprise apps with slow release cycles, and older versions of creative suites. Most consumer software has already been updated; the stragglers are exactly the niche, expensive tools that get used the longest.

The subtler risk for developers is toolchain components:

  • Native Node modules compiled for x86 in lockfiles or vendor directories
  • Ruby gems with C extensions built on an Intel machine and committed to the repo
  • Third-party Xcode plugins or build tools that shipped a universal wrapper but left an Intel-only helper binary inside the bundle
  • CLI tools installed via Homebrew before the Homebrew ecosystem completed its arm64 rollout
  • Docker containers running x86 images via Rosetta on Apple Silicon—those containers rely on the same translation layer and will also break

The file command is your fastest diagnostic:

file /path/to/binary

A native arm64 binary shows arm64. An Intel binary shows x86_64. A universal binary shows both. To scan an entire app bundle:

find /Applications/YourApp.app -type f -exec file {} \; | grep x86_64

macOS also has a graphical path: open System Information → Software → Applications and look for apps listed as Intel rather than Universal or Apple Silicon.

Auditing Your Build Pipeline

CI is the part most teams overlook. A developer’s local machine may already be M-series, but the build runner might be an older Mac mini, a GitHub Actions macOS runner that still defaults to x86, or a VM image frozen at a pre-Silicon snapshot.

Two things to verify now:

1. Your runner architecture. On any macOS machine or CI runner:

uname -m

arm64 means Apple Silicon. x86_64 means Intel. If your CI still runs on x86 today, it will break once the runner hardware upgrades and the host OS drops Rosetta—or when your runner ships macOS 28.

2. Your binary dependencies. Any tool pulled in by your build—CocoaPods, Fastlane, bundled scripts, embedded frameworks—should have arm64 slices. Run lipo -info on anything suspicious:

lipo -info /usr/local/bin/somedependency

If it returns only x86_64, you need either a universal build or an arm64-native replacement.

For App Store submissions this matters right now: Apple already requires arm64 slices for new submissions on modern SDK targets. The Rosetta deprecation is runtime enforcement catching up to submission policy—not a new requirement, just a deadline.

The Window You Actually Have

The practical deadline for most teams is before macOS Golden Gate ships in fall 2026, not before macOS 28 drops in fall 2027. Here is why: macOS 27 still runs Intel apps via Rosetta, which means you can test that your arm64 build works correctly while the fallback is still present. Once macOS 28 removes Rosetta, any regression in your native build is a hard crash with no translation layer to compare against.

Do the migration while the escape hatch is still open.

We’ve been shipping on Apple Silicon since 2022, but we still run the file audit on every new third-party SDK we integrate for our clients’ iOS and macOS products. An unexpected Intel dylib inside an otherwise-universal framework bundle remains a real occurrence—framework vendors ship universal at the top level and miss helper binaries buried three directories deep.

What We’re Watching

macOS Golden Gate developer betas are live as of June 8. The final release typically lands in September or October. The signal worth watching is whether Apple starts enforcing universal binaries at notarization or App Store review before the macOS 28 cutoff—they ran a similar pre-enforcement window with 32-bit apps ahead of the Catalina 64-bit mandate. If that pattern repeats, teams that wait until 2027 may hit an App Store wall sooner than expected.

If you build or ship a Mac app and haven’t done a binary audit since 2023, that is the action item from this post.

Sources

  1. macOS 27 Golden Gate Is the Last to Support Intel Apps via Rosetta 2 — MacRumors, June 10, 2026
  2. How to See Which Mac Apps Will Stop Working After macOS Golden Gate — MacRumors, June 12, 2026
  3. Apple Announces macOS Golden Gate — MacRumors, June 8, 2026
  4. macOS 27 Golden Gate is last update to support Intel apps — Cult of Mac, June 11, 2026
  5. MacOS 27 drops Intel support, will be last release with Rosetta 2 — OSnews, June 11, 2026