Universal Binary compatibility with old versions of MacOS

I built a universal binary and one of my users couldn’t use it - she said there was a message something like the file was corrupt. This is a non-technical user with an older Mac - I don’t know how old. I built an Intel binary and it worked fine.

The question: Do older versions of MacOS not understand the universal binary?

Most of my users are on Windows, and I’m really a novice with Mac. So I appreciate any information or advice. Thanks.

Universal binaries have been there for over 10 years.

PPC + Intel apps have been there on the last transition.

So older OS can handle it.

1 Like

You can even build one app with

  • PPC 32-bit
  • PPC 64-bit
  • Intel 32-bit
  • Intel 64-bit
  • Apple Silicon 64-bit

and put them all in one app.

Could have been user error. But I can also see how older OS wouldn’t know what to do with more recent binaries. I remember the days of PPC and Intel - wasn’t sure the current universal is the same. Thanks!

Did you code sign the software? The user may have misinterpreted Apple’s deliberately frightening message about unsigned apps.

2 Likes

UB has been around for a long time, with the format being unchanged.

You need to know what version of the macOS the customer is running.

Not code signed. Working on that … but without a developer ID - software isn’t being sold and only a few Mac users. Still learning Mac stuff…

Start there. ARM code absolutely requires a signature to run, even in debug - the IDE does this quietly for us. I suspect this is why an intel-only build worked for you, but that confuses me since you’re asking about older macOS and this would be a Big Sur / ARM issue.

Does that mean a xojo compiled app loaded on another M1 machine from a stick needs to be signed? If so that is very bad for “citizen developers” doing things for inhouse use at work!

1 Like

The way I understand it, yes.

Note that this is not a Xojo requirement, this comes from Apple.

1 Like

with any new apple “moving forward”, makes linux get more and more tempting !

1 Like

Since you mentioned Linux … a bit off topic here … but I’m also working on getting the app working properly on Linux. Seems to be some Linux improvements in 2021R1.1 but also some regressions. I’ll do feedback reports as I have time to verify them.

I’ve got several outstanding Linux feedbacks, two of which are quite egregious.

Tim,

I am confused about code signing. You mention that the IDE signs the app for us, while others in other dialogues have said that I need to get AppWrapper to sign my apps. Can you please explain what the IDE does, and does not do, in terms of code signing?

When you are using an M1 Mac and you debug-run, Xojo will build a native version to debug. As all ARM code needs to be signed to run, the IDE will ad-hoc codesign the debug build so that it can run. It is important to note that this is only for debug, AppWrapper is still the best way to code sign, notarize, and pack a release build with your distribution signature.

As I understand it, you are unable to ad-hoc code sign a build to run on another machine. You will need to sign with a developer certificate from Apple to distribute.

There’s some more information about the subject in general here: Apple Silicon Macs will require signed code – The Eclectic Light Company

2 Likes

Why is that, in fact?
While I recognise there are a lot of options that one may want to configure (where AppWrapper is really nice), I can also imagine someone wanting to sign a built app exactly like a debug one (so the Xojo IDE may propose to also sign built app).

And, if the user has no Apple account at all, how does the IDE sign (and run) a debug app? Using Xojo’s own account?

1 Like

We use what’s called an ad-hoc signature. Basically a signature that’s only good on the machine where it was signed. No certificate required.

1 Like

How does that work for remote debugging?

That’s a good point. Apple’s docs say:

If identity is the single letter “-” (dash), ad-hoc signing is performed. Ad-hoc signing does not use an identity at all, and identifies exactly one instance of code. Significant restrictions apply to the use of ad-hoc signed code; consult documentation before using this.

Here’s a more in-depth explanation of how this all works

So yes they’re good on other machines, but they don’t provide any proof that they haven’t been tampered with.