Epic: Support Apple Silicon

[sdmaclea]

Apple has announced plans to transition its Mac hardware line to a new Arm64-based chip that they refer to as “Apple Silicon”. This epic tracks the high level status of the milestones required to ship this feature in .NET 6.

.NET 6 will include new runtime id -- osx-arm64 -- for targeting this hardware. It refers to the macOS operating system running on Apple Silicon devices.

.NET Rosetta Emulation

• Support .NET with Rosetta 2 emulation Support .NET on Apple Silicon with Rosetta 2 emulation #44897 (Fixes in Big Sur 11.2 Beta2)

.NET 6 - CoreCLR Native

Functionality

• Support compilation targeting osx-arm64
• Modify code generation to support osx-arm64 security features
• Modify code generation to support osx-arm64 interop with native libraries

Testing

• Apple Silicon Prototype hardware available
• Manual testing of basic inner and outer loop tests
• Apple commercially shipping arm64 macos devices
• CI/CD Testing enabled
• CI/CD Stress testing enabled

Stability

• Basic tests passing rate > 99%
• Stress tests passing rate > 99%
• All tests passing rate > 99.9%

Availability

• .NET Core runtime nightly builds available
• ASP.NET Core runtime nightly builds available Enable ASP.NET Core on Apple Silicon aspnetcore#26821
• .NET Core SDK nightly builds available Build .NET SDK for Apple Silicon installer#8840 (See Epic: Support Apple Silicon #43313 (comment))
• .NET 6 preview available
• .NET 6 release available

Details

See Enable .NET Core on Apple Silicon for the full set of related PRs and issues.

.NET 6 - Mono

Functionality

• Support compilation targeting osx-arm64
• Modify code generation to support osx-arm64 security features
• Modify code generation to support osx-arm64 interop with native libraries

Testing

• Apple Silicon Prototype hardware available
• Manual testing of basic inner and outer loop tests
• Apple commercially shipping arm64 macos devices
• CI/CD Testing enabled
• CI/CD Stress testing enabled

Stability

• Basic tests passing rate > 99%
• Stress tests passing rate > 99%
• All tests passing rate > 99.9%

Availability

• Runtime nightly builds available
• .NET 6 preview available
• .NET 6 release available

/cc @richlander @mangod9 @janvorli @JulieLeeMSFT @sandreenko @tommcdon @steveisok @directhex @akoeplinger @jeffschwMSFT

[warrenrumak]

By the time .NET 6 is released, it will have been more than five years since Apple renamed this operating system to "macOS". It's not called "OS X" any more. If it can be done correctly in TFMs, it can be done correctly in RIDs.

[richlander]

Yup. Please file an issue @warrenrumak.

[lambdageek]

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

[eschwieb]

For Mono, I think the work item "Modify code generation to support osx-arm64 interop with native libraries" is done in the sense that the ABI is the same as ios which we already support. Is that right, @vargaz ?

Indeed. Apple has confirmed to me that the Apple silicon Mac ABI is precisely the same as their iOS ARM ABI.

[vargaz]

Yes, we don't support the arm64e stuff, but otherwise mono works on osx/arm64, both in the old mono repo and in dotnet/runtime. Couldn't run test suites because the sdk tools were hanging.

[sdmaclea]

@jeffschwMSFT I'm not sure if this is supposed to be a team epic. This was created with @richlander. I thought it was supposed to be a customer facing epic.

[jeffschwMSFT]

This feels like the right level of scope to me. Thank you for helping to keep our progress tracked and visible.

[ilushka85]

Given how quick things are coming for true arm64 for apple in 6.0 perhaps it makes sense to make the changes for 5.0 rather than trying to make it work on rosetta 2?

[richlander]

The belief is that people will want a supported .NET product on Apple Silicon before November 2021. That's why we are enabling 5.0 in R2 as well as enabling 6.0 to run natively. Also, there will be scenarios where 6.0 will need to run in R2 as well, so we might as well get that scenario working with 5.0.

[vitek-karas]

SDK should not allow to build anything for <6 osx-arm64 RID. But that's not what @taidang1902 failure is. That failure is the expected failure right now. The publish command chose 3.1 SDK (I'm guessing, but it's a pretty good guess), so it wants to run it on 3.1. The 6.0 arm64 hostfxr resolves the x64 3.1 framework installed and tries to load hostpolicy from it - and fails (arch mismatch).

If it worked, that command should still fail if the app is targeting 3.1 (and it probably does fail since it won't find the osx-arm64 runtime pack for 3.1).

[sdmaclea]

OK. There is a different failure when publishing for osx-arm4 < NET6. Basically the cryptic message in that case is about no suitable AppHost found.

[vitek-karas]

This would happen for any unsupported RID really - pick any RID which is supported in 6 and not supported in 3.1 and try it on 3.1 - the experience will be the same I'm afraid. But I understand that maybe we want to do better for this case, as it's more likely to happen.

[gnida-rada]

Is there a plan to have .NET Core 3.1 run on M1/Silicon Macs without Rosetta? Our problem:

1. Moving to .NET 6 is a significant investment for us that we cannot afford soon.
2. .NET Core 3.1 runtime sometimes calls dlopen (specifically, dlopen("libssl.x.x.x") in opensslshim.c). And it seems that when .NET runtime runs in Rosetta, dlopen() refuses to open libssl.x.x.dylib with only arm64 architecture.
3. installing openssl with homebrew installs arm64 only architecture that dlopen() will ignore (see 2 above)
   Thanks!

[iMonZ]

Is there a plan to have .NET Core 3.1 run on M1/Silicon Macs without Rosetta? Our problem:

1. Moving to .NET 6 is a significant investment for us that we cannot afford soon.
2. .NET Core 3.1 runtime sometimes calls dlopen (specifically, dlopen("libssl.x.x.x") in opensslshim.c). And it seems that when .NET runtime runs in Rosetta, dlopen() refuses to open libssl.x.x.dylib with only arm64 architecture.
3. installing openssl with homebrew installs arm64 only architecture that dlopen() will ignore (see 2 above)
   Thanks!

Theoretically it could work but it would be a bad experience for the customer. Same problem with QT.
I would recommend use Rosetta 2 until you can afford upgrading to .NET 6

[sdmaclea]

@gnida-rada There is no current plan to support 3.1 natively on Apple Silicon. If this is a significant issue, you should open a separate issue for it, so that it can be discussed in a separate thread.

[mangod9]

Will be closing this user story now. Only remaining issue is the intermittent NRE which we are continuing to investigate. There are some additional bugs which are tracked separately.

[iMonZ]

Will be closing this user story now. Only remaining issue is the intermittent NRE which we are continuing to investigate. There are some additional bugs which are tracked separately.

What’s with renaming osx to macOS?

[mangod9]

What’s with renaming osx to macOS?

Will need to move that to .net 7.

[iMonZ]

What’s with renaming osx to macOS?

Will need to move that to .net 7.

Oh no :(
I hoped this would come to the LTS.
That’s pretty sad
This would complete the new macOS support in the dotNet 6 version

[omajid]

Hey, @mangod9 do you have a link to the NullReferenceExceptions that you are tracking? I am interested in following that. We are hitting some NREs on non-macOS arm64 platforms as well, which might be the same or a different issue.

[mangod9]

Hi @omajid, here is the tracking issue for that: #51250.

[janvorli]

@omajid, most of the NullReferenceExceptions ended up being fixed by my change #53510 in preview 6. It was a general ARM64 issue.