In the Hello Developer newsletter for May 2026, published on May 12, Apple stated that macOS 27 will be the last release to include Rosetta. The communication does not appear in an official release note or a separate technical document: the text is in the Apple Silicon migration section of the monthly newsletter, with an explicit call to update Intel-based Mac apps before support ends.
macOS 27 is expected to be announced at WWDC26 on June 8, with public availability in autumn 2026. The following version, macOS 28, will not include Rosetta according to Apple’s communication. The timeline is roughly one year: developers who start migration now have until the macOS 28 release to finish it, though development, testing, and distribution cycles reduce the effective margin.
macOS 27 Rosetta: what this means for Intel apps and x86 dependencies
The announcement affects three categories of developers. The first is apps that have never been recompiled for Apple Silicon: if an app has only an x86_64 binary with no arm64 slice, it stops running on Apple Silicon Macs as soon as Rosetta is removed. The second category covers apps that are already updated but carry dependencies that are not: third-party libraries, plug-ins, extensions, closed-source frameworks with Intel-only binaries. Rosetta stops working for those components as well. The third category involves CI/CD pipelines with agents or tools that have not been migrated: a build system that uses Intel binaries for signing, notarizing, or testing apps fails the same way.
Apple notes in the newsletter one specific exception for “older gaming titles using Intel-based frameworks.” The newsletter does not provide technical details, so relying on this exception without explicit confirmation from Apple would be premature.
The practical difference from previous years is that Rosetta has absorbed the migration pressure until now. Once macOS 28 reaches users, non-migrated apps simply stop launching.
How to check your exposure
The starting point is knowing which binaries in your app are not native Apple Silicon. Activity Monitor shows, in the “Kind” column, whether a process is running as Apple, Intel, or through Rosetta. For a more precise analysis on distributed binaries, use lipo -info <binary_path>: if the output shows only x86_64, the binary has no arm64 slice and requires Rosetta to run.
For Homebrew dependencies, start with brew list --formula, then run file $(brew --prefix)/bin/<tool_name> to check the architecture of each executable. Many Homebrew packages now ship with a universal or native arm64 binary, but those installed before the Apple Silicon transition may not, especially if the tap is not actively maintained.
Instruments, with the “CPU Profiler” template running on an Apple Silicon Mac, highlights threads executing through Rosetta. App Store Connect shows whether the app in the catalog is distributed as a universal binary: in the “App Information” section, the “Supported Architectures” field lists arm64 only if the uploaded build includes the correct slice.
For CI pipelines, the critical point is often the build agent. GitHub Actions uses Apple Silicon runners for macos-14 environments and later, but if workflows execute custom x86_64 binaries (scripts, proprietary tools, sidecars) without having verified them, the pipeline can work today via Rosetta and break without obvious warning after the removal.
Accessibility Nutrition Labels: what the audit requires
The same newsletter introduces a second topic for developers: Accessibility Nutrition Labels. They are currently voluntary and Apple has not communicated a mandatory deadline. The concept is to declare explicitly, in the app’s App Store information, which accessibility features the app supports.
The required audit covers five areas: VoiceOver, Voice Control, Dynamic Type, Dark Mode, and Differentiate Without Color. This is not simply about declaring formal support; it requires verifying that each feature actually works in the app without broken behaviors. An app that does not crash VoiceOver but does not meaningfully support it does not pass the audit in the way Apple intends.
The operational work takes time: testing VoiceOver across every screen of an app is non-trivial manual effort, especially if accessibility was not a first-class requirement when the app was built. Starting now puts you in a better position than waiting for it to become a submission requirement.
Apple has not communicated when Nutrition Labels will become mandatory. If the pattern follows other App Store requirements, the gap between announcement and enforcement is typically six to twelve months, but no specific timeline has been confirmed.
What to watch in the WWDC26 cycle
WWDC26 on June 8 is when Apple will publish the technical details of macOS 27. Among the concrete things to expect: updated migration tooling, official deprecation notices for Rosetta in macOS 27 beta release notes, and potentially dedicated Apple Silicon migration sessions.
The Hello Developer newsletter is a meaningful signal, but it is not a formal deprecation notice with version specifics and complete migration instructions. That documentation will come with the WWDC betas. Marking June 8 on the calendar and reading the macOS 27 beta release notes as soon as they are available is the most concrete step you can take right now.
