Intel, Universal 1 or 2 apps

Globet wrote:

So I'm a bit confused on the Intel/silicon issue. I see recommendations that installing Rosetta 2 will enable the use of Intel-based apps, but elsewhere I see that Rosetta support is to be dropped when a future version of MacOS is launched.

Universal 1 and Rosetta 1 is roughly twenty years back, and no longer relevant.

Universal 2 is current, shows as Universal, and is relevant for old app versions and for effectively if not actually unmaintained apps.

Support for Intel x86-64 apps is going away in macOS 27, except for a few specifically unmaintained games.

So far I'm not seeing much evidence of even majors (Amazon, for example in their desktop Music app, Intel only, offering a silicon-compatible version? Can anyone clarify? I already have several notifications popping up reporting that some of my apps will need to be updated...

Which apps, and do those apps have newer versions?

If Amazon’s desktop music app is not updated for instance, don’t update to macOS 27 when that arrives, and then check with Amazon for updates or alternatives for macOS 27.

Some of the printer vendors haven’t updated their apps in some years, and some of those apps might even be unnecessary for AirPrint / TWAIN / ICA printers and scanners.

These macOS 26.5 app notifications are presumably all trying to warn people about their old apps before the macOS 27 betas arrive, and break the old things.

Also probably to encourage the vendors to update their apps for Apple silicon Macs, that having first been released back in 2020.

Or to not rush a macOS update when some critical app hasn’t been updated or replaced.

Even the Finder lists a Univesal2 application as an Application for its Kind in List View. Microsoft Word has been a Universal2 binary for several years now… and v16.108.2 certainly is. If you were to perform a Finder Get Info on Word, it would show it as Application (Universal) which is aka Universal2. Some vendors offer explicit arm64 or x86_64 (Intel) built applications.

Easiest way is Finder

1. Right-click the app >> Get Info
2. Look at Kind

You’ll see:

Application (Intel) >> runs via Rosetta 2

Application (Universal) >>this is Universal 2

Apps from Mojave ?

Will never be Universal 2 (it didn’t exist yet)

Application are either:Intel 64-bit (x86_64) >> works via Rosetta 2

32-bit Intel >> won’t run at all (dropped in macOS Catalina)

So realistically, anything you migrated from macOS 10.14 Mojave

If it launches >> it’ is  Intel 64-bit

If it does not >>likely 32-bit

Illustration 1 below does contain the option to open that specific application in Rosetta

Second illustration does Not have the option to open in Rosetta

Both application are denoted a " Universal "

Need_help_give_help wrote:

Hi MrHoffman

Quote: “Apps labeled Apple silicon and Universal are what will continue to be supported, and Intel or 32-bit not so much.”

I implore you to read the whole of the discussion because what you say is not necessary true, as they could be Universal 1 apps, designated just Universal in Kind column, so will not run in Mac OS28

The text of mine you quoted answers this, just not in a way you would seem to prefer.

There are four types of universal apps here: those that contain Intel x86-64 and no Apple silicon code, those that contain code for Apple silicon only, those continuing (at least) Intel x86-64 and Apple silicon code (and conceivably other code), and those apps containing Intel x86-32 and neither Intel x86-64 nor Apple silicon.

The four types:

• Intel x86-64 only ❌⚠️
• Apple silicon only ✅
• Intel x86-64 and Apple silicon ✅
• Intel x86-32 without x86-64. 🆖

The key:

❌ Intel x86-64, and likely not supported on future macOS versions (except for certain games, per Apple docs)

✅ likely will be supported on future macOS versions

🆖 Intel x86-32 is not supported on and doesn’t run on macOS 10.15 and later (details)

⚠️ Will (should) trigger a Rosetta deprecation warning.

If an application is actually "Universal 2" with both Intel and ARM binaries, I would expect it to continue working no matter what particular string ("Universal" or "Universal 2") Apple programs the Finder to display.

If by some chance, you copied an old "Universal 1" binary onto a modern Mac, I don't know what the Finder would show for its type; but even if the application still ran under Tahoe, it would stop working when Rosetta 2 went away.

The following article explains the app warnings that are generated on current macOS 26 systems, how to manually identify apps that might or will be problems on macOS 27, how various apps can be updated, and related details:

• Using Intel-based apps on a Mac with Apple silicon - Apple Support

The System Report list of installed applications can potentially be useful here, as well:

• Get system information about your Mac - Apple Support

You’ll see the column labeled kind listing as “Universal’, “Apple silicon”, or “Intel”, or as “32-bit (unsupported)”. The two former kinds are desirable here. The latter two, not so much.

Apps labeled Apple silicon and Universal are what will continue to be supported, and Intel or 32-bit not so much.

I expect there will be more info as macOS 27 becomes available.

Unless you are developing apps and checking for compatibility, and only if you have a spare Mac and spare Apple Account and spare data and where the Mac doesn’t need to be uncorrupted and stable or even functional or compatible with your important apps, skip the betas.

Key Aspects of Universal and Universal 2 Binaries:

• Structure: They use the "fat binary" (Mach-O) format, bundling separate code "slices" for each architecture into one file.
• Performance: They run natively, avoiding the performance overhead of Rosetta 2 translation.
• Development: Developers create them using Xcode 12.2 or later, which adds the arm64 architecture to standard build settings.
• Automatic Selection: At runtime, the macOS operating system automatically chooses the appropriate code slice for the current hardware.

History: The concept was first used during the PowerPC to Intel transition (2005–2006) and reintroduced for the Intel to Apple Silicon transition (2020–present).

Universal vs. Universal 2

• Original Universal: Supported PowerPC and Intel (x86) architectures.
• Universal 2: Supports Apple Silicon (ARM64) and Intel (x86_64) architectures.

Using Intel-based apps on a Mac with Apple silicon - Apple Support

Update Intel-based apps for Apple silicon

Updating an Intel-based app for Apple silicon means replacing it with a "Universal" or "Apple silicon" version of the app.

• If you got the app from the App Store, you can use the App Store to find and install updates.
• Some apps offer a built-in way to get updates. Look for a "Check for Updates" option or similar in the app’s menus or settings.
• You can also check the developer’s website for a "Universal" or "Apple silicon" version of the app. Or contact the app developer to learn whether an update is available or planned.
• Some apps might include or use components, such as extensions or updaters, that need to be updated separately.
• If you added functionality to your app by installing Intel-based plug-ins, extensions, and other add-ons from a different developer, update those as well.

About Intel-based apps, Rosetta, and the transition to Apple silicon

Need_help_give_help wrote:

Owl-53

You have misunderstood what I said as I obviously wasn’t clear enough.

Although, as I said,  I have experimented with Mr Hoffman suggestion of using the “File” command I am also not confident yet that I am doing it right.

I would consider using the Rosetta alerts to identify the important apps headed for problems, and using the “kind” column in the system report list of applications to be “doing it right”.

It is true Mr Hoffman might not have been saying ‘don’t install Xcode’ but I’m not putting words in his mouth.

Downloading a suite of command line developer tools or adding an enormous suite of graphical developer tools seems unwarranted at this juncture.

Particularly when an existing macOS command can provide the same info.

And this particularly when manually looking up stuff on individual files, rather than using an automated report showing the same information for all apps is available.

Xcode can wait.

As to your method it might work perfectly but at this stage I am not going to try it out for the very reason you give: “Proceed with an abundance of caution using an unknown Terminal Commands”

The most reliable way to do this is not (harmless) file, not (harmless) lipo, not (huge, harmless) Xcode, not internal details of Universal binaries, the it is looking at the Rosetta-deprecation alerts (which will be shown for the apps you actively use), and looking at the “kind” column in the installed-applications report (for the old apps you need but are you’re not routinely using). A column which shows the necessary info, same as it did (and still does) for x86-32 to x86-64.

Having been through all of this millennium’s PPC to x86-32, x86-32 to x86-64, and now x86-64 to Apple silicon migrations, Apple is pretty good at dealing with all this migration stuff. Read the “kind” column in the system report showing installed applications.

Need_help_give_help wrote:

Hi Globet et al

 I return to my original post and subsequent discussion above.

There is no way that we have been able to verify that if an app is designated Universal in App/Kind it is Universal 1 or Universal 2. It needs to be Universal 2. (Not to be confused with the other issue of 32/64 bit apps)

There is a way to determine if an application is Intel only, Universal, Apple only and if it was written during the PPC / Intel era using the original Rosetta

It will requires the Command Line add on for Xcode 

The specific command used is lipo

Look it up 

If used properly, an application written for PPC / Intel using the original Rosetta 

The output contains any of the following architectures, the application was built during the PowerPC era of the Mac

ppc

ppc64

Examples ppc i386

This indicates a Universal Binary that supports both PowerPC and Intel Macs.

ppc

This indicates a PowerPC-only application.

Examples of PowerPC-era output from lipo -archs:

ppc i386

ppc64 x86_64

Proceed with an abundance of caution using an unknown Terminal Commands

Notice the fine & detailed differences different between the two ?

• Original Universal: Supported PowerPC and ➡️ Intel (x86) ⬅️ architectures.
• Universal 2: Supports Apple Silicon (ARM64) and ➡️ Intel (x86_64)⬅️ architectures.

At present, the listing in your screen shot, will show only Universal without the designation of Universal 2

Need_help_give_help wrote:

We can be under a false sense of security if we see Universal against an app but not know whether that is Universal 1 and therefore not work.

Why does it matter so much whether the GUI tells you the difference between Universal 1 and Universal 2?

There are two main reasons why a Universal 1 binary might not run under macOS 11 through 27.

• It contains 32-bit Intel code. In that case, since no version of macOS that can run on an Apple Silicon Mac supports 32-bit Intel applications, the application would already be broken and you couldn't run it on Apple Silicon Macs now.
• It depends on something else that has changed / been deprecated since Universal 1 binaries were common.

It is quite likely that many Universal 1 applications already do not work under Tahoe because of one or both of these factors. But if you did have Universal 1 applications that worked under Rosetta 2, there is a method that might help you to find them: looking at the date for the application in the application's Get Info box.

The first version of macOS that ran on Apple Silicon Macs (Big Sur) came out in November 2020, so if you see Universal applications with dates much older than that, that would be a strong hint that they were Universal 1 applications that were coded well enough to run under current versions of macOS, but that would break when macOS 28 came out.

Globet wrote:

Shouldn't Apple take some sort of a lead on this? Comms are confusing (for example - go to the Apple store for updated apps for silicon" seems only to apply to current Apple's own apps). Apple must be aware of (or can check) which apps sold on the store are of Kind Intel, Universal 1, or Universal 2. Maybe a flag on the store to indicate an app as "silicon compatible"? Vast majority of users don't become aware of this type of issue until it bites them...

Apple shows alerts for actively-used apps.

I’d assume Apple doesn’t show alerts for infrequently used or unused apps, because that’d bury many folks in alerts about their old and unused apps. They didn’t show alerts for unused stuff last time, either.

For those that want or need more details… As happened with the x86-32 to x86-64 transition at macOS 10.15 some six years ago (and that 32- to 64-bit app transition having started with OS X 10.4 and OS X 10.5, an aeon or two ago) the folks that want to inventory their entire macOS app installation catalog can use the existing macOS app inventory tool, the same inventory tool that was used previously, the same inventory tool that still shows the app kind. Which is the key to this whole discussion.

This thread is a discussion about the details and underpinning of macOS apps, including Mach-O and app bundles and about the migration from x86-64, as well as about the migration from x86-32, and from PPC, too.

This thread is not how I would suggest approaching the upgrade to macOS 27.

For where this is all headed, Apple will undoubtedly discuss that at WWDC26 next week.

And for completeness, I would (as a user) also not rush to upgrade to any new macOS version. Let Apple and the third-party app developers and other users find and fix and document whatever issues might arise.

If, however, you're an app developer or are managing or supporting IT, you will need test systems, and will want to test macOS 27 ahead of your users. Maybe this testing work includes running some betas too, and betas should only happen on testing machines, and not with any data you need to be available and uncorrupted, and not any hardware or any third-party apps you need to be available and uncorrupted.