Author Topic: Universal Binary is bad idea in this case!  (Read 977 times)

Offline PaulDerden

  • Newcomer
  • *
  • Posts: 3
    • View Profile
Universal Binary is bad idea in this case!
« on: November 06, 2024, 03:42:09 PM »
The application in the "FAT format" of Universal Binary is compiled for several architectures. In this case, for 2 architectures - for x86_64 and ARM64. Accordingly, such an application weighs 2 times more and loads the system a little more at startup because you need to extract your architecture from fat binary files

If I remember correctly, the beta versions of Universal Binary on Mac with M1 were compiled so that the application could be run both in normal native mode and via Rosetta.
This makes some sense, because it happens that Intel/x86_64 versions of the application have some functions that work differently or vice versa.

But starting with the first release version of Universal Binary, there is no longer a "Run using Rosetta" checkbox in the application properties, although the application is compiled for both architectures.
https://forums.camerabits.com/index.php?topic=16478.0

I suspect that it is impossible to run the application through Rosetta, because the Intel/x86_64 version of the program uses AVX instructions (and they cannot be emulated/translated into arm64)

What is the point/benefit for the end user in Universal Binary if only 1 architecture can be run?
The disk space is not rubbery and I would like to avoid storing something on the disk that will never be used.

If the application continues to compile in such a way that it cannot be run through Rosetta, then it makes sense to compile a separate application for each architecture

Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 25020
    • View Profile
    • Camera Bits, Inc.
Re: Universal Binary is bad idea in this case!
« Reply #1 on: November 06, 2024, 04:17:25 PM »
Paul,

The application in the "FAT format" of Universal Binary is compiled for several architectures. In this case, for 2 architectures - for x86_64 and ARM64. Accordingly, such an application weighs 2 times more and loads the system a little more at startup because you need to extract your architecture from fat binary files.

Nothing is extracted.  The touched code pages (for the architecture in use) are paged into the application's address space and are utilized.  The other architecture's pages are unused, not loaded, etc.  The only time all of it is accessed is during the Gatekeeper procedure that verifies the app is signed by an Apple-authorized developer.

If I remember correctly, the beta versions of Universal Binary on Mac with M1 were compiled so that the application could be run both in normal native mode and via Rosetta.
This makes some sense, because it happens that Intel/x86_64 versions of the application have some functions that work differently or vice versa.

But starting with the first release version of Universal Binary, there is no longer a "Run using Rosetta" checkbox in the application properties, although the application is compiled for both architectures.

I changed nothing in this regard between the release candidate and the final release.  But why would you want to run the application under Rosetta2 anyway?

I suspect that it is impossible to run the application through Rosetta, because the Intel/x86_64 version of the program uses AVX instructions (and they cannot be emulated/translated into arm64)

You could create a x86_64 Terminal window and open it from there and I expect that it would run under Rosetta2.  If you'd like to know how, I can point you to some instructions.

What is the point/benefit for the end user in Universal Binary if only 1 architecture can be run?

Simplicity.  No confusion.  If we offer two links to the architecture-specific versions, some percentage of users will download the wrong version.  Downloading the wrong version on an Apple Silicon system will still allow the app to run under Rosetta2 emulation, but for the Intel-based system, downloading and running the Apple Silicon version will fail to run altogether.  This creates confusion and increases support costs.  Note that we do not charge for our support either here on the forum, nor via email/phone.  Making the software easier to download and run serves both our interests and our user's interests.

The disk space is not rubbery and I would like to avoid storing something on the disk that will never be used.

It is possible to strip the unwanted architectures if you really need ~150MB of disk space back.  I can point you to instructions if you're interested.

If the application continues to compile in such a way that it cannot be run through Rosetta, then it makes sense to compile a separate application for each architecture

If enough users agree with you, then I'm sure we'll eventually go this route, but it does increase the burden on our development/build time and testing.  This will decrease the time we have to devote to developing new features (and fixing problems.)

-Kirk

Offline Kevin M. Cox

  • Hero Member
  • *****
  • Posts: 545
  • PM 2024.10 (8173) | macOS 15.1
    • View Profile
    • Kevin M. Cox | Photojournalist
Re: Universal Binary is bad idea in this case!
« Reply #2 on: November 06, 2024, 05:16:04 PM »
Quote
What is the point/benefit for the end user in Universal Binary if only 1 architecture can be run?

Apple's intent for Universal applications is to simplify the end user experience by not requiring them to understand or even know about processor architectures.

Quote
This makes some sense, because it happens that Intel/x86_64 versions of the application have some functions that work differently or vice versa.

Here is why Apple says you might need to force a Universal app to run under Rosetta:

From: https://support.apple.com/en-us/102527
Quote
Some universal apps (apps that don't need Rosetta) include the setting “Open using Rosetta.” This setting enables a universal app such as a web browser to use plug-ins, extensions, or other add-ons that do need Rosetta, because they haven't been updated to support Apple silicon. If a universal app doesn't recognize an add-on that you installed for the app, you can quit the app, select this setting, and try again.

This doesn't apply to Photo Mechanic.

Quote
If enough users agree with you, then I'm sure we'll eventually go this route...

Please don't. There is no reason to ship separate applications for all the reasons you mentioned above.

I've been running the Universal release since the first beta and it was noticeably faster than the older Intel only builds. I can't fathom why anyone would want to purposefully run PM under Rosetta now that it is Universal.
Kevin M. Cox | Photojournalist
https://www.instagram.com/kevin.m.cox/

Offline PaulDerden

  • Newcomer
  • *
  • Posts: 3
    • View Profile
Re: Universal Binary is bad idea in this case!
« Reply #3 on: November 07, 2024, 12:10:37 AM »
Guys, I am not noob in Mac.

I know what is Rosetta (Rosetta 2) and how install it on new Macs

The main complaint is that why would I, as a user, have an application for 2 architectures if I can only run it for 1 architecture.

There is no checkbox in the properties of the PhotoMechanic 2024 application for launching via Rosetta, but in other applications there is

P.S.
It on Macbook Air M1 with macOS Sequoia 15.1

Offline PaulDerden

  • Newcomer
  • *
  • Posts: 3
    • View Profile
Re: Universal Binary is bad idea in this case!
« Reply #4 on: November 07, 2024, 12:15:19 AM »

Simplicity.  No confusion.  If we offer two links to the architecture-specific versions, some percentage of users will download the wrong version.  Downloading the wrong version on an Apple Silicon system will still allow the app to run under Rosetta2 emulation, but for the Intel-based system, downloading and running the Apple Silicon version will fail to run altogether.  This creates confusion and increases support costs.  Note that we do not charge for our support either here on the forum, nor via email/phone.  Making the software easier to download and run serves both our interests and our user's interests.

-Kirk

Yes, I understand you, but there is an alternative option that will remove the confusion - you can make an installer in .pkg format and under the hood in the preinstall script you will determine the architecture of the computer on which pkg is running and unpack/extract from the package the version of the application compiled for this architecture

Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 25020
    • View Profile
    • Camera Bits, Inc.
Re: Universal Binary is bad idea in this case!
« Reply #5 on: November 07, 2024, 06:46:56 AM »
Paul,

The main complaint is that why would I, as a user, have an application for 2 architectures if I can only run it for 1 architecture.

There is no checkbox in the properties of the PhotoMechanic 2024 application for launching via Rosetta, but in other applications there is

It is because of the attached property in the application property list file (Info.plist) in the application bundle.  There is no reason to allow the user to force a different architecture since the application is self contained and has no possibility of incompatible plugins.  This will make it so the user always has the best experience when running the software.


Offline Kirk Baker

  • Senior Software Engineer
  • Camera Bits Staff
  • Superhero Member
  • *****
  • Posts: 25020
    • View Profile
    • Camera Bits, Inc.
Re: Universal Binary is bad idea in this case!
« Reply #6 on: November 07, 2024, 06:52:20 AM »
Paul,


Simplicity.  No confusion.  If we offer two links to the architecture-specific versions, some percentage of users will download the wrong version.  Downloading the wrong version on an Apple Silicon system will still allow the app to run under Rosetta2 emulation, but for the Intel-based system, downloading and running the Apple Silicon version will fail to run altogether.  This creates confusion and increases support costs.  Note that we do not charge for our support either here on the forum, nor via email/phone.  Making the software easier to download and run serves both our interests and our user's interests.

Yes, I understand you, but there is an alternative option that will remove the confusion - you can make an installer in .pkg format and under the hood in the preinstall script you will determine the architecture of the computer on which pkg is running and unpack/extract from the package the version of the application compiled for this architecture

I understand your position and we will consider your request.

-Kirk