MAS submission in 2022, M1, Intel, x86, Universal

Targets macOS
1

  • I haven’t updated my apps on MAS since the M1 was released, I still don’t have an M1 machine, and now I need to release an MAS update.

  • My app uses a lot of .dylibs included in the MacOS folder of the application bundle.

Because of the dylibs, and the fact I’m using an Intel machine, I assume I should continue compiling my app as x86 in Xojo, right?

And as long as Rosetta is there on the M1 machines, my app should continue working as-is, right?

(I know at some point I’ll be forced to buy an M1. I always put these things off as long as possible.)

Thanks!

2

Because of the dylibs, yes. When you have Universal dylibs you can build Universal with Xojo from an Intel machine.

Yes.

You may be pleased to know that you won’t be forced to buy a machine for the sole purpose of releasing a M1 build. You’ll be able to build M1/Universal from your Intel machine once you have the M1/Universal dylibs.

* Of course you’ll need at least Xojo 2020r2 to build M1

>> I do not know if the Mac App Store is rejecting Intel-only apps <<

1 Like
3

Thanks. Forgot to mention I’m using the latest Xojo 2021r3.1

I compiled the .dylibs myself some time ago. There are a lot of dependencies, and I had to copy over some libs from the OS folders and use terminal commands to make all the libs point only to the other libs in the bundle. So it looks like unless I get an M1 and do all that again, I’m stuck with an x86 app.

That second step of copying over .dylibs from OS folders now also has me a little worried…

  • Question: are the system .dylibs “universal” on M1 macs?

If not, I guess this app won’t be able to be “universal”, and I’ll have to release 2 versions?

4

My honest advice is to wait until you have an M1 machine to test with.
The ARM frameworks within the macOS are iOS ABI compatible, NOT macOS ABI compatible. So things internally are different and can operate differently. Xojo will shield you from from the differences that Xojo know about.
Sticking with Intel for the time being is the best way to ensure that your application works the way you expect on M1 machines.

5

Up to now, there is no problem submitting to MAS intel only apps.

6

Okay, thank you all for the helpful info and advice!

7

It may or may not depend on which library you are talking about. For a quick test I picked one at random and checked it. It was Universal.

/usr/lib/ssh-keychain.dylib: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit dynamically linked shared library x86_64] [arm64e:Mach-O 64-bit dynamically linked shared library arm64e]

However, I would think that you shouldn’t need to bundle system libraries into your app. It might be worth reviewing your build process.

If you’re interested, it is possible to rent M1 machines in the cloud. I did so to work with homebrew in a clean environment. I used macincloud.com with success and was pleased.

2 Likes
8

Releasing an app for M1 without having one is possible.
You can cross compile your app (and dylibs) on the Intel Mac and ship to customers.
But that is a risky move since you wouldn’t be able to test it.

So get a M1 Mac, maybe refurbished if you are low on cash.

9

Thank you for checking! And, that’s interesting (macincloud).

The app was first released around 2010. Bundling a bunch of dependencies with it was the only way to ensure operation across different versions of macOS at that time. When I updated it to 64-bit a few years ago, it was the same situation. I doubt that will be different now or in the future, but I could be wrong.

10

It all depends on the libraries. For instance, we do need to bundle our own OpenSSL to verify Apple provided mac app store receipts. It’s silly.

Best wishes,
Tim :slight_smile:

1 Like
11

That’s an understatement.

13

Conversation above says it all, about Apple, the Computer manufacturer.

Tho’, I’ll never use another one.