macOS 26.4 starts nagging your users about every Intel app you never recompiled

The transition that started at WWDC in June 2020 has an ending now, and it looks like a dialog box. Apple’s developer news post confirms two things: macOS 26.4 will prompt users whenever they launch an app running under Rosetta translation, and Mac App Store universal apps that already require macOS 13 or later can ship ARM-only binaries today. Neither is dramatic on its own. Together they’re the eviction notice.

2020

Rosetta 2 shipped with the first Apple Silicon Macs as the thing that let your entire Intel software library keep working while everyone waited for native builds. It was always framed as a bridge, not a destination. Six years is a long bridge. If you’ve been quietly running an x86_64 line-of-business app this whole time because “it still works,” that decision is about to generate feedback.

26.4

Here’s the part that matters for your phone. Starting in macOS 26.4, launching an app that Rosetta has to translate produces a system prompt telling the user the app is Intel-based and should be updated. Read the announcement carefully on one point: this is a notification, not a block. The app still runs. Rosetta is not being removed in 26.4, no matter how the headlines want to phrase it. But you know exactly how this plays out — the user doesn’t read the dialog, they read the word “update,” and then they call you at 2 a.m. asking why the finance tool is broken. It isn’t broken. It’s just been told it’s old in front of everyone.

13

The App Store change is narrower than it sounds and cleaner than you’d expect. If your Mac App Store app’s deployment target is already macOS 13 Ventura or later — meaning every Mac that can install it runs Apple Silicon anyway — you can drop the Intel slice and submit an arm64-only binary. No Intel Mac on Ventura+ exists, so the x86_64 code was dead weight the whole time. Smaller download, one architecture to test, one less thing to sign. This is Mac App Store submission policy specifically. Don’t confuse it with a general rule about every binary you ship.

0

That’s the number of changes this makes to notarization. Dropping the Intel slice does not affect the notary service. Notarization checks code signing, the hardened runtime, and entitlements — it has never cared how many architecture slices are in the Mach-O. An arm64-only notarized app is exactly as valid as a universal one. If someone tells you that going ARM-only requires re-tooling your notarization pipeline, they’re guessing.

Two commands

Before 26.4 lands, find out what you’re actually running. Scan your app directories for anything without an arm64 slice — those are your future support calls:

1
2
3
4

for app in /Applications/*.app; do
  bin="$app/Contents/MacOS/$(defaults read "$app/Contents/Info" CFBundleExecutable 2>/dev/null)"
  [ -f "$bin" ] && printf '%-14s %s\n' "$(lipo -archs "$bin" 2>/dev/null)" "$app"
done | grep -v arm64

Anything printing x86_64 alone is Intel-only and will translate. And to confirm whether a process is currently running under Rosetta at runtime:

1

sysctl -n sysctl.proc_translated   # 1 = translated, 0 = native

Feed the first one into your fleet tooling and you get an inventory of what needs a native build, a vendor chase, or a retirement plan. Internal notarized tools, old vendor agents, that one PDF utility procurement bought in 2019 — those are the ones that bite in six months, not your headline apps.

No date

Apple has not committed to a hard removal date for Rosetta, and I’m not going to invent one. The public signal remains that broad Rosetta support continues through this OS cycle before narrowing to a smaller set of older frameworks. That’s the honest state of it. But the direction is not ambiguous. When a vendor starts making the OS apologise for your software on every launch, the countdown has started — they just haven’t put the number on screen yet.