Let's say I'm on a macOS Monterey, MSVS2022 and I'm developing the visual app using .net6, which supports both Intel macs and m1 macs natively now.
I can setup and build my app as x64 to be launched on Intel macs for sure.
With a big pain and a bunch of editing the .csproject file I can also build the same app as arm64, so run it natively (without Rosetta) on modern m1 macs.
However, since it is the same app, it seems inappropriate to me to ship two apps instead of one, like it is done by a lot of other companies when they ship their mac software. Another reason, my app will be deployed without user clicking on correct link, so I want to have like universal app, with all archs in one. I understand, that the size of my app will be bigger, and it is ok for me.
Apple allows me to do that with native code relatively easy: just build in Xcode for two archs.
For thrid-party build systems and libraries, I usually can do the same thing using lipo tool from Xcode tools the one can merge two binaries of two different architectures into one universal binary, which will be run natively on both platforms.
.net was created as cross-platform framework, so I think it is OK to expect from it at least the same ability to create one application with different archs support inside it.
Unfortunately, I've not found any mentions of how to do so, and even if it possible or not.
I've tried to do it myself, but not succeeded. The .net app bundle on mac contains next parts of our interest:
I've tried to compose the universal binaries of (1) and (2.1), but then it turns out, that dlls (2.2) are different too (in a way it could not run with the wrong ones), and I don't know how to compose them.
So, my questions I would appreciate to be helped with are:
Set both supported runtime IDs in your project file:
<RuntimeIdentifiers>osx-x64;osx-arm64</RuntimeIdentifiers>
Now, when you build; you'll get separate intermediate folders for both identifiers, but your bin
will also contain a merged (universal) .app that supports both architectures natively.
For any native libraries you supply yourself or include via nuget, you'll need to make sure you have versions for both architectures.
.NET DLLs are compiled to intermediate language and aren't architecture specific (in this case).