macOS 27 is Apple Silicon only: the arm64-only build is good news for local inference

Apple opened App Store submissions for the 27 SDKs on September 10, published the Xcode 27 Release Candidate, and repeated the line that matters for anyone doing native work: macOS 26 Tahoe is the last release with Intel and Rosetta support. macOS 27 is Apple Silicon only. Submissions start on September 14, and from April 2027 building against the 27 SDK becomes the minimum for the App Store.

How we got here

The signal was visible all summer. On July 20 Apple seeded the release candidate of macOS 26.6, iOS 26.6 and iPadOS 26.6, and 26.6 was expected to be the last big Tahoe update. Tahoe 26.6 went GA on July 27 with security fixes and a Spotlight already optimized for macOS 27; Xcode 26.6 RC left beta the same day with Swift 6.3 and Gemini available as a coding agent inside the IDE. Then on September 10 the 27 cycle became concrete: Xcode 27 RC, submissions open, arm64 only.

So the sequence is: the last Intel OS shipped in July, the arm64-only successor is in RC in September, and the store deadline for the new SDK is April 2027.

Why arm64-only is good news for local inference

Every local model stack on a Mac already assumes Apple Silicon. MLX does not run on Intel at all. The Metal backend of llama.cpp and the memory math in sizing unified memory on a Mac both presume the GPU and CPU share one pool. What macOS 27 does is remove the pretense that anything else exists, and that removal has three concrete effects for people shipping inference tooling.

• One baseline for SIMD. NEON, Accelerate and Metal are the floor, not an optional fast path. There is no x86 branch to keep alive, no AVX fallback to test, no ifdef forest in the hot loop.
• A smaller CI matrix. If you ran an Intel runner only to prove a universal binary still launched, that job is deletable the day you drop macOS 26 support.
• No Rosetta surprises. A Python wheel or a helper binary that silently ran translated on x86 will simply fail to load on 27. That is better than running slow without telling you, but you need to find those dependencies now.

An arm64-only macOS does not make your model faster. It makes the fast path the only path, which is what performance-critical code wanted all along.

The Neural Engine and MLX story in MLX and Core ML on Apple hardware is the same story from the framework side: Apple's own libraries have been arm64-first for years, and the OS is now catching up to the frameworks.

What to do before September 14

• Download Xcode 27 RC and build your native targets with the architecture set to arm64 only. Watch for anything that only compiled because a universal slice was carrying it.
• Run your inference benchmarks on the macOS 27 SDK build and compare against your 26.6 numbers. If tok/s moves, you want to know before users tell you.
• Grep your dependency tree for x86-only binaries: old Homebrew bottles, vendored tools, Python packages with prebuilt wheels. Anything that relied on Rosetta needs a native replacement.
• If you distribute through the App Store, check the new age-rating questions and product-page assets Apple added for the 27 submissions.
• Write down the hard date: April 2027 is when building against the 27 SDK stops being optional.

The honest limitation

The clean baseline only helps you if all of your users are on Apple Silicon too. An internal tool for a team that still has Intel Macs in the fleet cannot drop macOS 26 support just because the OS did, and that means one more release cycle of universal binaries and the CI job that proves them. The briefs I am working from also do not list which Apple Silicon models macOS 27 supports, so an M1-era cutoff, if there is one, is something to verify against Apple's own compatibility list before you set a deployment target. For the local-inference stack itself, though, the direction is unambiguous: arm64, unified memory, Metal, and nothing else left to maintain.