← Field Notes
Rosetta 2 · Deep dive

Apple's Rosetta notice is rare by design, and its silence proves nothing

R Rob Flanagan · · 14 min read

I could not make the notice appear on a clean macOS 26.5 VM. The daemon's own log said why, and the reason is more useful than the notice.

If you manage Macs on macOS 26.4 or later, there is a notification that warns users their Intel apps are on the way out. You have almost certainly not seen it. I spent an evening trying to make it appear on a clean macOS 26.5 virtual machine and failed, repeatedly, while an Intel binary sat running under translation the whole time.

The notice is real. What surprised me is how much has to go right before it fires, and what Apple says may not set it off at all.

What it actually says

Here it is, captured on build 25F71:

Support Ending for Intel-based Apps This version of "Legacy Intel App" will not open in a future release of macOS. Learn how to update to an Apple silicon version.

It is an ordinary Notification Center banner in the top-right corner. It does not auto-dismiss. Worth knowing, because Apple uses three different nouns for it. The pre-release Platform Deployment guide says "pop-up notification". The Device Management reference says "pop-up dialog". The user-facing support article just says "notification". Only the last one matches what a Mac actually draws.

The first attempt produced nothing

My test app was a minimal Cocoa app compiled for x86_64. It launched, ran under translation, and appeared in the process list as Intel. No notification, on any launch, for as long as I watched.

The subsystem responsible is not Rosetta. It is ecosystemd, a daemon in Ecosystem.framework, paired with a per-user ecosystemagent that posts the notification. It explains itself in the default log, no debug flags needed. log show --last 15m --predicate 'process == "ecosystemd"' answered the question in one line:

[GAME_CHECK] type=process bundle=com.example.legacyintelapp
             result=undetermined(Bundle ID not tracked by GamePolicy) uid=501

The daemon's own strings spell out what happens next:

<ecosystemd: GamePolicy> Unable to determine game status for %s: %s - suppressing until determined

Every candidate app is run through a game filter before anything is shown, because of the carve-out Apple is keeping for older unmaintained games past macOS 27. An app the filter cannot classify is silenced. Not deferred. Silenced, until something changes its mind.

My app only became eligible after it was code-signed, given an LSApplicationCategoryType, installed in /Applications, and registered with LaunchServices. The verdict flipped and the notification fired on the next launch:

[GAME_CHECK] ... result=notGame uid=501
[NOTIFICATION_SENT] decision=launch reason=valid name=Legacy Intel App
             bundle=com.example.legacyintelapp path=/Applications/LegacyIntelApp.app uid=501
             text=This version of "Legacy Intel App" will not open in a future release of macOS...

A test app in /tmp is admittedly not a normal deployment, and I changed four things at once, so I cannot tell you which one flipped the verdict. What the run does show is the shape of the rule: an app the filter could not classify stayed silent, and the filter is not built to give it the benefit of the doubt.

Be careful how far you carry that, and I want to be the one who says it rather than the commenter who does. The game filter is what silenced my app. Software that is deployed normally, signed and categorized and registered, clears that filter on the first launch exactly as mine did the moment it looked ordinary. So the filter is not what keeps the notice rare on a real fleet. Whatever is doing that sits above it, in the part Apple does not log values for.

The rest of the gating

Which brings us to the part that does apply to normally deployed software. The game filter is one stage of several, and the daemon names the rest when it loads its policy:

[POLICY_LOADED] enabled=%d appRateLimit=%d overallRateLimit=%d
                periodicInterval=%d catchupInterval=%d pluginNotifications=%d

and on startup in my VM:

[INIT] gameFilterEnabled=1 knownLauncherFilterEnabled=1 policyEnabled=1 assetsLoaded=yes

So: a policy that arrives as a downloadable asset, a game filter, a known-launcher filter, server-delivered exclusion rules, a per-app rate limit, and an overall rate limit. Re-launching the same app never re-notified me. Each new notification needed a fresh bundle identifier.

The asset part is the one worth sitting with. Ecosystem.framework carries an AssetManager, an AssetPolicyProvider and an ExclusionRules mechanism, which means Apple can change how loudly this behaves without shipping a macOS update. Whatever cadence you measure today is not a property of the OS version you are on.

Which is also why I am not going to tell you the notice is uniformly rare. Glenn Fleishman describes it firing not just on first launch but again after a restart, and there are people in Apple's own discussion threads who say they see it at every login. Those accounts and mine can all be true at once if the cadence is policy-driven rather than fixed. That is the point.

That matches what people report. MacGeneration wrote in March that despite several attempts they could not get the alerts to appear on release builds at all, and did not report their first one until an update on 1 May. Read their account closely, though, because it cuts both ways: the notice they finally got was for an app whose developer had temporarily reverted to an Intel build. A native app went Intel and the system noticed. That is the notice working, not a rate limiter relenting. Apple told developers the cadence was accelerated during the beta period, in a 26.4 release note quoted by MacGeneration and, in English, by an Apple engineer in the developer forums. I have not read that note on an Apple page myself. Either way it is a good reason to treat any beta-era account of how often this fires as no guide to a release build, and Apple publishes no cadence for either.

There are five notices, not one

Pulling the English strings out of Ecosystem.framework on 26.5 gives thirteen keys, five of which are notification bodies. Four of the five I did not find quoted anywhere in the research for this piece:

TriggerTitleBody
Intel app launchesSupport Ending for Intel-based AppsThis version of "%@" will not open in a future release of macOS. Learn how to update to an Apple silicon version.
App with an Intel componentSupport Ending for Intel-based AppsThis version of "%@" includes a component that will not work with a future release of macOS. Learn how to update to an Apple silicon version.
Native app loads an Intel plug-inAction Recommended for This Plugin"%1$@" loaded the third party Intel-based plugin "%2$@". Check for an Apple silicon version of the plugin for compatibility.
Periodic, one appApp Update RecommendedYou recently used one app that still relies on Rosetta. Check with the developer for an Apple silicon version to ensure compatibility with macOS 28 or later.
Periodic, several appsApp Updates RecommendedYou recently used %1$d apps that still rely on Rosetta. Check with the developers for Apple silicon versions to ensure compatibility with macOS 28 or later.

Two things jump out.

The launch notice names no version. "A future release of macOS" is all a user gets. The periodic summary, on the other hand, names one: macOS 28 or later. If you have been telling people that macOS 28 is a number the community invented, this is Apple's own operating system saying it to end users. The number is Apple's. What is wrong in the popular paraphrase is the verb, not the version.

The third row is the interesting one. A native app that loads a third-party Intel plug-in gets its own notification, with its own title. The app is fine. The plug-in is not.

The blind spot Apple documents itself

That plug-in notice does not save you, and Apple says so. From the macOS 27 release notes, issue 176042635, filed under Rosetta and Deprecations:

Intel-based plugins and loaders may not appear in Settings or trigger notifications of their incompatibility. All Intel-based software will no longer be compatible with macOS 28.0, excluding legacy games.

Note the second sentence, because somebody will paste it at you. What ends at macOS 28.0 is compatibility for Intel software generally, with the legacy-games carve-out surviving. That is a narrower claim than "the Rosetta code is deleted", and a different claim again from the Intel hardware date further down. Three statements, three scopes.

Apple then lists where to go looking, which is the most immediately useful sentence in any of this:

Check common plugin locations for VSTs, HAL, ARA, PDEs, Color Pickers, Quicklook & Spotlight plugins/extensions/components, such as: ~/Library/Audio/Plug-Ins/* ~/Library/Printers/ ~/Library/ColorPickers/

Read the first sentence again. The inventory surfaces Apple built may not show these, and the notifications may not fire for them. This is Apple documenting the hole in its own tooling, in the release notes for the version that ships the tooling.

It also explains a pattern that has been confusing users since spring. People kept insisting the notice was spurious because Get Info said their app was Universal. In the threads I read, most of those cases dissolved on inspection. Apple's user-facing article is precise about it: you get a notification when "the app or a component used by the app" will not work. A Universal app with an Intel printer driver, an Intel updater, or an Intel audio plug-in is a genuine Intel dependency wearing a native jacket.

An audit that walks /Applications and reads the architecture of each app bundle will not find any of this. I say that as someone who wrote an Extension Attribute that walks /Applications and reads the architecture of each app bundle. That tool is still worth running. It is the app layer, and the app layer is the easy half. I also described this notice in July as fair warning to someone sitting at their Mac. Having now watched the daemon decide, I would not describe it that way again.

macOS 27 changes the shape of the problem

Three items from the same release notes, all filed under Rosetta or EcosystemUI:

Rosetta does not survive the upgrade. Issue 163213094: "If Rosetta was previously installed, it is not automatically restored after upgrading to macOS 27.0." Apple files this as a deprecation. Separately, issue 168097174 notes that apps a user had set to "Open using Rosetta" will launch natively instead, which quietly discards a per-app setting somebody chose on purpose.

Background services get no prompt. This one is not mine and I have not watched it happen, so take it as reported by two named parties. PaperCut restamped its KB on 12 August while I was writing this. It says the Rosetta reinstall prompt "will only appear for user-initiated apps". It then names what does not get one: "System services, for example the Print Provider, Application Server, Secondary server etc, will not prompt for Rosetta installation." A following paragraph adds the consequence: "As a result, apps requiring Rosetta may fail to run after upgrading to macOS 27." Glenn Fleishman reported the removal-and-reprompt behavior at Six Colors on 3 August, though he states the prompt unconditionally, the first time you need Intel code. The user-launch-only limitation is PaperCut's alone. If PaperCut is right, the interactive half of your Intel estate heals itself and the daemon half fails without saying anything. The mitigation is one command you can already push: softwareupdate --install-rosetta --agree-to-license.

Installer packages flip to arm64. Issue 171187112: "Installer packages which specify no hostArchitecture will now default to arm64. Ensure any pre and post install scripts behave as intended under arm64. Additionally, audit any remaining installer plugins to ensure compatibility on Apple silicon." Apple filed that under Rosetta rather than under packaging, which tells you how they see it.

macOS 27 also ships a user-facing Intel inventory. Issue 175697313: "Settings > General now lists Intel-based apps that will be incompatible with macOS 28.0. The list also identifies unused Intel-based software discovered on the system." Apple's own note says Settings and General. Two outlets that have used the pane give two different full navigation paths beyond that, neither with a screenshot, so take the exact route as unsettled until you have clicked it yourself. What matters more is that 176042635 is describing the blind spot in exactly this list.

The two dates people keep merging

Apple has made two separate statements about Intel Macs, and they answer different questions.

macOS 26 is the last macOS release with full support for Intel-based Mac computers.
Apple will continue providing software security updates for Intel-based Mac computers for three years.

The first is about a release. The second is about a duration. Keep the quotation marks around "full support", because Apple has not defined it anywhere, and that undefined qualifier is the entire hinge. It permits a state that is not full support, which is what the second sentence describes.

Then there is the part nobody can resolve. Apple does not say three years from what. There is no "from", no "starting", no "after", no end date, and no second Apple page that supplies one. Three years from macOS 26 shipping lands around September 2028. Three years from the point Intel drops off the current release lands around September 2029. The trade press has published both, confidently, which is a good indication the ambiguity is real rather than manufactured.

One of those readings is just Apple's ordinary support window, the current release plus the two before it, applied to macOS 26. The other needs Apple to extend past that. Apple has not said which it means, and that is the whole problem: a refresh plan anchored to the wrong end of the gap is wrong by twelve months, which is a procurement cycle.

Both of those sentences come from a page that still carries a pre-release banner, verbatim, re-checked on 12 August: "The features discussed on this page are pre-release versions and may be incomplete, changed, or removed before final release." Worth knowing how much of this piece rests on provisional Apple text. The notice itself, the restriction key and the Rosetta timeline all have shipped sources with no banner on them. The two sentences above carry that banner, and every macOS 27 release note quoted here comes off a page currently titled Golden Gate Beta 5, which is its own kind of provisional. Re-read all of it before you build a plan on it.

The restriction, and why you might not want it

The control is allowRosettaUsageAwareness. I checked the spelling character by character against the shipping OS, not just the documentation. It sits in the RestrictionsPlugin binary on 26.5, next to a localized description that renders in German as "Erkennung von Rosetta-Nutzung zulassen". Allow detection of Rosetta usage.

Two details Apple documents that are easy to miss. It lives in com.apple.applicationaccess, the ordinary Restrictions payload, so it lands in whatever restrictions profile you already ship. And it defaults to true, which means the notification is on unless somebody turns it off. Jamf exposed it in the Blueprints Restrictions component in April. FileWave ships it as a restriction setting from 16.4. The Custom Settings recipe circulating from March is no longer the right advice for most fleets.

I have not verified that setting it to false actually stops the notice, and neither has anyone else I can find. That sounds like an odd thing to be unable to confirm, until you remember that nobody could reliably trigger the notice in the first place. You cannot demonstrate the suppression of an event you cannot summon.

Before you deploy it, though, weigh what you are switching off. The notice was never a complete signal. Apple says it may skip plug-ins entirely, it suppresses anything the game filter cannot classify, it rate-limits, and Apple can retune it from the server. Turning it off costs you the loud, partial half of a signal that was already missing the quiet half.

What I would actually do

Run an app-layer inventory, and know that it is the floor rather than the ceiling. Then go after the layer the notice cannot see: the plug-in and loader paths Apple listed, printer drivers, audio components, Quicklook and Spotlight extensions, and anything with an installer plug-in.

Before macOS 27 lands anywhere, decide what happens to Intel background services on upgrade. If PaperCut is right, pushing softwareupdate --install-rosetta --agree-to-license as part of the upgrade path costs nothing and covers the failure mode that produces no user-visible symptom.

And when you brief anyone above you, give them the two dates as two dates. The last release with "full support" for Intel hardware is one planning object. Three years of security updates from an unstated starting point is another. They are not the same number, they are not on the same axis, and merging them is how a hardware refresh ends up scheduled a year late.

The notice firing tells you something. The notice not firing tells you nothing at all.

Sources

Primary sources, retrieved 2026-08-11 and re-verified against the live pages 2026-08-12. Apple wording is quoted verbatim from the live page except where the text is explicitly attributed to someone else quoting it. Observations marked as captured were taken on macOS 26.5 build 25F71 in a clean virtual machine with no configuration profiles installed:

← Back to Field Notes