What's the difference between 'Apple' and 'Universal' binary apps?

[Apple Knowledge Navigator]

I was just browsing through my apps see which were still Intel-only, and I noticed that some are labelled as 'Apple' rather than 'Universal' (examples below).

These are only third-party and for the most part are Adobe or music production-related. Does it have something to do with the app being written from the ground up specifically for Apple Silicon?

Thanks

 

[hwojtek]

In most cases it is not "written from the ground up". It's just compiled for Apple Silicon only (with some modifications to the original code which wouldn't actually compile if not modified). Apple Silicon-specific apps obviously are exclusive to this platform and might be called "written from the ground up".

 

[leman]

Unless I am mistaken, “Apple“ means that the app includes only ARM binary while “universal“ means both ARM and Intel binary. In other words, you can copy a universal app to an Intel Mac and it should run.

 

[Apple Knowledge Navigator]

Unless I am mistaken, “Apple“ means that the app includes only ARM binary while “universal“ means both ARM and Intel binary. In other words, you can copy a universal app to an Intel Mac and it should run.

Thanks. So what is the advantage of an 'Apple' binary? That it was made specifically for Apple Silicon?

 

[mystery hill]

So what is the advantage of an 'Apple' binary? That it was made specifically for Apple Silicon?

Smaller file size.

 

[chabig]

On Apple Silicon machines, Intel code has to be translated before it will run. This is a one-time occurrence, as the translated code is saved for future use. So the 'advantage' is that no translation is required to run Apple Silicon code.

 

[mystery hill]

So the 'advantage' is that no translation is required to run Apple Silicon code.

That isn’t an advantage over Apple Apps because Universal Apps include both Intel and Apple Silicon binaries.

 

[madeirabhoy]

Smaller file size.

the correct answer.

 

[leman]

Thanks. So what is the advantage of an 'Apple' binary? That it was made specifically for Apple Silicon?

As @mystery hill wrote: smaller file size. There is no additional advantage.

 

[chabig]

That isn’t an advantage over Apple Apps because Universal Apps include both Intel and Apple Silicon binaries.

Of course. That's correct. I was thinking about Intel binaries.

 

[boak]

Aren't Apple apps more efficient than Universal apps?

 

[chabig]

They are more space efficient, because they are smaller (no Intel code).

 

[Mr. Awesome]

Aren't Apple apps more efficient than Universal apps?

No. Apple apps are just compiled for M-series Macs only, while Universal contain binaries for both M-series and Intel Macs.

 

[jdb8167]

As @mystery hill wrote: smaller file size. There is no additional advantage.

One of the applications listed is Mx Power Gadget. This will only run on Apple silicon. I guess someone could put up a message on a Universal binary version that explains why it won't run on Intel but that seems unnecessary. So the other benefit of only have an ARM binary is that macOS will put the international "do not" symbol 🚫 over the application on an Intel Mac.

 

[boak]

No. Apple apps are just compiled for M-series Macs only, while Universal contain binaries for both M-series and Intel Macs.

I see. I thought Universal apps were simply Intel apps translated for M chips.

 

[Mr. Awesome]

I see. I thought Universal apps were simply Intel apps translated for M chips.

No, you’re thinking of apps that run under Rosetta. Almost any regular Intel app can run under Rosetta on M hardware, but it’ll still show as an Intel app.

 

[Spaceboi Scaphandre]

I was just browsing through my apps see which were still Intel-only, and I noticed that some are labelled as 'Apple' rather than 'Universal' (examples below).

View attachment 2049182
View attachment 2049183

These are only third-party and for the most part are Adobe or music production-related. Does it have something to do with the app being written from the ground up specifically for Apple Silicon?

Thanks

Nothing's different. Apple means it was made for Apple's custom ARM64 chips, while universal means the app can run on both Intel x86 and Apple ARM.

 

[Apple Knowledge Navigator]

Nothing's different. Apple means it was made for Apple's custom ARM64 chips, while universal means the app can run on both Intel x86 and Apple ARM.

Thank you. Out of interest though, why would this be the case for apps they are the same on both Intel and AS? For instance the Adobe ‘Apple’ binary apps are, from what I can tell, identical to the Intel counterparts. Why would they be Apple and not Universal?

 

[Spaceboi Scaphandre]

Thank you. Out of interest though, why would this be the case for apps they are the same on both Intel and AS? For instance the Adobe ‘Apple’ binary apps are, from what I can tell, identical to the Intel counterparts. Why would they be Apple and not Universal?

Because a lot of people still use Intel Macs and there's no reason not to. I mean, there's no difference between Universal and Apple apps other than Universal can also be used on Intel. There's no performance loss, so there's nothing to worry about.

But there is one advantage to a Universal app: In case the ARM mode doesn't work properly you can force Rosetta 2 to start running so you can run it in x86 mode to fix any possible issue, so you got a failsafe. I have to do this with a couple Steam games as their ARM versions are kinda buggy.

 

[Apple Knowledge Navigator]

Because a lot of people still use Intel Macs and there's no reason not to. I mean, there's no difference between Universal and Apple apps other than Universal can also be used on Intel. There's no performance loss, so there's nothing to worry about.

But there is one advantage to a Universal app: In case the ARM mode doesn't work properly you can force Rosetta 2 to start running so you can run it in x86 mode to fix any possible issue, so you got a failsafe. I have to do this with a couple Steam games as their ARM versions are kinda buggy.

I get you, and it allows the developer to work on them independently from one-another.

I would also guess that in case of Adobe, they’re probably looking to the future and want to focus on a stable native platform. So the Creative Cloud app is a good start as it doesn’t require the same development as the actual suite of other apps.

I just find it interesting because it raises the question of what the performance gains might be once more developers focus solely on Apple silicon.

 

[Spaceboi Scaphandre]

I get you, and it allows the developer to work on them independently from one-another.

I would also guess that in case of Adobe, they’re probably looking to the future and want to focus on a stable native platform. So the Creative Cloud app is a good start as it doesn’t require the same development as the actual suite of other apps.

I just find it interesting because it raises the question of what the performance gains might be once more developers focus solely on Apple silicon.

Well there's some things that cannot go fully ARM. Some 3D graphics APIs are only available on x86 so they have to stay on Intel. And there's some tasks that require more power than the standard ARM power output which is why Rosetta 2 exists so the Apple Silicon chips can go full x86 mode when they need to.

 

[jdb8167]

Well there's some things that cannot go fully ARM. Some 3D graphics APIs are only available on x86 so they have to stay on Intel. And there's some tasks that require more power than the standard ARM power output which is why Rosetta 2 exists so the Apple Silicon chips can go full x86 mode when they need to.

I’m not sure I understand what you are saying. What graphics APIs aren’t available to Arm but are available to Intel. Apple supports Metal and OpenGL on both. What “more power” are you talking about? If anything you get more from native than you can get from translated x86-64 instructions. Rosetta 2 only supports a subset of x86 instructions.

 

[mr_roboto]

I see. I thought Universal apps were simply Intel apps translated for M chips.

For most developers, their app isn't "Intel", it's code entirely written in high level languages like Objective-C and Swift. These abstract away most low level details of the CPU's instruction set. If they want to build for just Intel, they uncheck all build targets other than Intel in Xcode. If they want to build Universal, they check both Intel and Apple, and when the app is compiled it actually gets compiled twice - once for each target - and then the binary code is packed into a single file using Apple's 'fat' binary technology.

So you shouldn't think of Universal as being Intel apps that have been translated to Arm. It's really bundling both an Intel app and an Arm app (each of which has been compiled from the same CPU-agnostic source code) in a single file.

Universal isn't a new technology. During some of the years following Apple's PowerPC to x86 transition, Xcode fully supported no less than four CPU targets: 32-bit PPC, 32-bit x86, 64-bit PPC, and 64-bit x86. You could build a fat binary which supported all four in one file.

 

[ponzicoinbro]

Universal isn't a new technology. During some of the years following Apple's PowerPC to x86 transition, Xcode fully supported no less than four CPU targets: 32-bit PPC, 32-bit x86, 64-bit PPC, and 64-bit x86. You could build a fat binary which supported all four in one file.

‘FAT’ apps also existed on OS 7.5 containing a binary for Motorola 68x and PowerPC. Apple has done this for even longer.

 

[Toutou]

Well there's some things that cannot go fully ARM. Some 3D graphics APIs are only available on x86 so they have to stay on Intel. And there's some tasks that require more power than the standard ARM power output which is why Rosetta 2 exists so the Apple Silicon chips can go full x86 mode when they need to.

Literally nothing in this post makes any sense whatsoever. Why would you even post this?