I would like to drive to consensus around this section. At least from here to the primary design alternative described in Open Questions below.

As I wrote the Open Questions, it was clear the second alternative may be easier and perhaps more preferable. This alternative may make it easier to support publishing universal binaries.

How are other runtimes/SDKs with global installs planning to address this problem?

It may be useful to look at Java, golang, python, rust, ... to see whether there is a trend.

• I couldn't find an Oracle JDK for Apple Silicon.
• Zulu OpenJDK was arch specific.
• golang was arch specific.
• Python was a universal binary (signed by Apple)
• Python3 was arch specific from a homebrew cask.
• Rust looks like it is not ready. They are still protoyping.

Our muxer architecture, readytorun story, and legacy mixed architecture make it more complicated.

From this list, it sounds like arch specific is the norm and we won't be an outlier if we stick with the simpler arch-specific as well.

Xamarin.Mac is what runs on Apple Silicon (and it's jitted):

Is that the correct message if we considering coreclr JIT to be backend for Xamarin.Mac ?

Right, we would need to make this work as part of adding support for coreclr w/ Xamarin.Mac.

I'd be better to fold this into https://github.com/dotnet/designs/pull/182/files#diff-f9955dc1a401114b9383fdfecab5a55da35312f33af1af21d4d46a0246fa7e16R158 section. It also needs clarification of what is exactly not supported.

Running apps via dotnet app if both x64 and arm64 is supported by the dotnet - this is currently problematic because there's nothing in the app.runtimeconfig.json which would hint the dotnet/hostfxr which architecture the app needs.

• We would either have to add this information somewhere (.runtimeconfig.json is probably the most natural place for this)
• Rely on app (executable) instead
  • Currently this is disabled by default for MacOS RID targets (if I remember correctly) - this fact is not discussed anywhere in this doc either
  • Requires signing - as mentioned above

The universal muxer should default to one architecture if it doesn't know better (probably arm64)

there's nothing in the app.runtimeconfig.json which would hint the dotnet/hostfxr which architecture the app needs.

This is intentional design. We talk about these as cross-platform apps that can run anywhere.

I know of the existence of "portable apps" - that's why the muxer will need a "default" architecture (for those apps). The point was about current state of things where we don't generate apphost for apps on MacOS and thus they're executed via dotnet app.dll. Those apps may not be portable, but currently there's no way to tell which RID they were built for (if any) and will break in bad ways if run on the wrong architecture (for example if they have native dependencies).

If we solve the signing problem and turn on apphost by default for MacOS, then this problem becomes much less important and we can probably continue to ignore it (just like we ignore it on Win x86/x64 today).

My personal preference:

• Choose a different location for installation of x64 .NET 6+ runtime - something like dotnet_x64. The existence of this is transient and in some not so distant future release will go away
• The primary install location for .NET 6+ will be arm64 only (for the most part)
  • Keep the muxer/hostfxr as universal binaries in the main install location
  • Add some logic to also look for runtimes/SDKs in the dotnet_x64 location - the universal muxer/hostfxr would use this to get the right runtime if asked to run x64 app
• The primary location would be the only one registered (in config file and so on) and it would be the only one on "path".

After reading this document, the above statement by @vitek-karas would be my preference for a solution.

Choose a different location for installation of x64 .NET 6+ runtime - something like dotnet_x64.

Are you proposing we backport this change to the 3.1/5.0 branches.

I was thinking we could only do this for the .NET 6+ branches.

I guess the advantage of @vitek-karas's approach would be that we just need to teach the installer to alter the install path for x64 on Apple Silicon.

That seems easier that fixing it overwriting the dotnet and hostfxr universal binaries.

That said, I am leanig to @vitek's approach too.

If we never install .NET 6+ x64 into global location (we simply don't produce the installers for this) then the dotnet_x64 approach is not much different from keeping everything in dotnet. Obviously this is ignoring the potential problems with overwriting the dotnet (note that hostfxr doesn't have a problem since it's installed into a version specific directory, so the older installers will never overwrite the newer one).

The only true advantage of having dotnet_x64 is that it would allow to install both .NET 6 x64 and .NET 6 arm64 side by side.

The only true advantage of having dotnet_x64 is that it would allow to install both .NET 6 x64 and .NET 6 arm64 side by side.

It would also give us a pattern to follow - which is important here. Having a process that we can fallback on is important for our customers and ourselves when we rediscover this problem in 18 months.

? .NET 5 goes out of support short after .NET 6 ships. .NET 3.1 is supported for much longer.

@rolfbjarne @marek-safar Is this requirement documented anywhere?

I haven't heard anything about it, but it wouldn't surprise me if Apple made it required at some point.

AFAIK it's the default setup for xcode projects but still a recommendation. I agree with Rolf that this can change in the future.

not yet formally required by Apple, but something we fully expect to be required later this year. As an example, Apple started mandating that all apps have 64-bit slices in their universal binaries about a year before they started telling people that 32-bit was ending. We know they will stop building Intel-based Macs within the next 18 months or so, so we expect them to start requiring Arm slices this summer.

Have you seen the work we have done on this? https://docs.microsoft.com/en-us/dotnet/core/install/macos-notarization-issues

When running the equivalent unsigned binary from a Rosetta 2 emulated process the process is not killed.

I think that this is temporary to allow easier transition and it will be locked down.

@odhanson Might be able to provide more context.

I will try gather more information both about the signing and the Apple store requirements and comment back here.

Here is a link:
https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11_0_1-universal-apps-release-notes

Code Signing
New Features
New in macOS 11 on Macs with Apple silicon, and starting in macOS Big Sur 11 beta 6, the operating system enforces that any executable must be signed before it’s allowed to run. There isn’t a specific identity requirement for this signature: a simple ad-hoc signature is sufficient. This new behavior doesn’t change the long-established policy that our users and developers can run arbitrary code on their Macs, and is designed to simplify the execution policies on Macs with Apple silicon and enable the system to better detect code modifications. This new policy doesn’t apply to translated x86 binaries running under Rosetta 2, nor does it apply to macOS 11 running on Intel-based platforms.