Developers can target macOS UI with .NET 6

[maddymontaquila]

This work is the evolution of existing Xamarin.Mac solution but built on CoreCLR VM foundations. The goal is to expose macOS APIs to allow developers to leverage macOS APIs such us Cocoa, Catalyst system and other native macOS APIS in the way they can build applications which run locally or are distributed via Mac App Store.

Work Items

• Low-level API support for Objective-C scenarios Low level API support for Objective-C scenarios #44659
• Thread and ThreadPool support for reference-counted resources API proposal: System.Threading.ThreadPool.RegisterWorkItemHandler method #44213 NSAutoreleasePool instance should be added to all threads. #52023
• Enhance CoreCLR GC to support reference-counted interop
• Support for Catalyst TFM Add Mac Catalyst TargetFrameworkIdentifier #44882 Add Mac Catalyst (iOS API, Mac ABI) runtime #47823
• Enable Catalyst Runtime Packs Enable Catalyst Runtime Packs #47517
• Apple Silicon Support Epic: Support Apple Silicon #43313
• Signal manipulation for existing scenarios where users have custom crash reporting mechanisms.
  • Mono semantics: https://www.mono-project.com/docs/advanced/signals/
• [.NET 6]: Determine if the IDE needs updates to support Mac Catalyst asset resources xamarin/xamarin-macios#10818
• Mac Catalyst: should we have Runtime.Arch? If so, what should it return? xamarin/xamarin-macios#10312
• Mac Catalyst: make sure archiving works xamarin/xamarin-macios#10413
• [dotnet] Native ICU libraries not ready for Catalyst xamarin/xamarin-macios#11392
• Mac Catalyst: fix introspection failures xamarin/xamarin-macios#10215
• Mac Catalyst: review API surface xamarin/xamarin-macios#10216
• .NET 6: add arm64 support to Mac Catalyst and macOS xamarin/xamarin-macios#10700
• Mac Catalyst: AOT for ARM64 xamarin/xamarin-macios#11724
• Mac Catalyst: compute LSMinimumSystemVersion from MinimumOSVersion in Info.plist xamarin/xamarin-macios#10452
• Deprecate and remove Xamarin types which conflict with predefined .NET types xamarin/xamarin-macios#10508
• [.NET 6] Change the identify of the Xamarin.iOS.Tasks.dll and Xamarin.Localization.MSBuild.dll so that they're not duplicated across packages. xamarin/xamarin-macios#9835
• .NET 6: add support for specifying additional partial Info.plists that are to be merged into the final Info.plist xamarin/xamarin-macios#10646
• Automatically include .framework or .a files in the NuGet's runtimes/ios/native folder xamarin/xamarin-macios#11667
• Xamarin iOS should call monovm_initialize for .NET 6 xamarin/xamarin-macios#10504
• Decorate all APIs with correct SupportedOSPlatform attributes xamarin/xamarin-macios#10170
• .NET: Use UnmanagedCallersOnlyAttribute instead of (or in addition to) MonoPInvokeCallbackAttribute xamarin/xamarin-macios#10470
• Audit reflection usage in our assemblies xamarin/xamarin-macios#10405
• .NET 6: remove the concept of binding projects and add support for binding native libraries/frameworks to normal library/executable projects xamarin/xamarin-macios#10254
• [.NET] Build time is slower xamarin/xamarin-macios#10251
• .NET: SingleView app size xamarin/xamarin-macios#10249
• [.NET 6] Implement API diff for our .NET assemblies xamarin/xamarin-macios#10210
• [.NET] Optimize support for app extensions xamarin/xamarin-macios#10051
• [.NET] Add support for AOT-compiling into frameworks xamarin/xamarin-macios#9727
• Use .NET-specific min OS versions to build native code for .NET xamarin/xamarin-macios#10659
• .NET 6: set PackageType to DotnetPlatform xamarin/xamarin-macios#10679

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[jkotas]

If we need compatibility for the existing bindings, we may also need to add "Special handling of nint/nuint/nfloat" in CoreCLR. Related: #4233 #13788

[AaronRobinsonMSFT]

@rolfbjarne and @janvorli I have added a checkbox above for validating the signally logistics as they relate to customer crash collection mechanisms. I need to defer for how to validate these scenarios.

/cc @jeffschwMSFT

[jeffschwMSFT]

This is also an area where coreclr and mono provide different experiences. For mono providing a hook so that textual traces would be produced was at the tip of possible. coreclr provides an x-plat post mortem diagnostic experience (out of proc). So this is likely an area where we can provide an enhanced experience in addition to the signal approach, but perhaps instead of that one as well.

[rolfbjarne]

@jeffschwMSFT my main concern is that we don't prevent people from using custom crash-reporting mechanisms, and in that regard it's important to know if CoreCLR are using signals in any way right now (for instance: are NullReferenceExceptions implemented by handling SIGSEGVS like they are on Mono? And what out floating point exceptions such as division by zero / SIGFPE?)

Also on some platforms it's not possible to do anything out of proc (this is the case on iOS - which is currently not a target platform for CoreCLR, but may be in the future).

[janvorli]

@rolfbjarne we use signals for handling hardware exceptions like SIGSEGV and SIGFPE on Linux, but not on MacOS where we use exception ports (I was planning to migrate to signals on macOS too soon). But we only handle them when they occur in our code (managed code for both and SIGSEGV also in a few related JIT helpers). When they happen at other places, we call the previously registered handler to give a chance to handle it e.g. in a custom host.
If a native shared library loaded after the runtime registers such handler, we currently rely on it behaving the same way - handling the signals only when they know the signal belongs to their component and calling the previous handler if they don't.
One important thing to note is that we register the SIGSEGV handler as using an alternate stack so that we can handle stack overflow and print full managed stack trace when it occurs. That might be something that the previously registered handlers may have a problem with. Our handler is able to run on both alternate stack and regular stack though in case some other component registers a SIGSEGV handler running on a regular stack and calls back to us.

[rolfbjarne]

@janvorli I think we'll have to come up with some solution then, because that will interfere with third-party crash reporters.

If a native shared library loaded after the runtime registers such handler, we currently rely on it behaving the same way - handling the signals only when they know the signal belongs to their component and calling the previous handler if they don't.

The purpose of a crash reporter is to detect and report crashes anywhere in an app, and they all assume that SIGSEGV/SIGFPE are bad and should be treated as a crash (rightfully so IMHO). They have no way of knowing that SIGSEGVs/SIGFPEs in certain parts of the app shouldn't be fatal.

The way we solved this with Xamarin was to let mono handle any signals first, and then chain to the previous handler (like CoreCLR doing) + add API to have third-party code (re)install mono's signal handlers, so that third-party code doesn't have to be initialized before mono (which is usually not possible).

This is described here: https://www.mono-project.com/docs/advanced/signals/

This use case is narrow enough that I don't think we have to provide an identical API in CoreCLR, but we should at least find a solution to the problem.

[jkotas]

What are the third-party crash reporters that this is important to solve for?

[rolfbjarne]

@jkotas

What are the third-party crash reporters that this is important to solve for?

Crashlytics is one example of a third party crash reporter some of our customers use.

[bruno-garcia]

Sentry is another crash reporting tool with customers using Mono on iOS/macOS.

[danmoseley]

@steveisok @marek-safar can we close this now? are any tasks remaining for the 6.0 release?

[joperezr]

@steveisok @marek-safar friendly ping 😄

[marek-safar]

We can close it if it's bothering you but this will be fully completed after GA

[joperezr]

Not bothering for sure 😄 just doing bookkeeping on issues marked as 6.0 for our areas. If this will be completed post 6.0 but it's not finished yet, I'll just switch the milestone.

[mairaw]

This issue title seems to be targeted at .NET 6 and I'm trying to clean up the .NET 6 project. Do we need to update the issue or create a new one?

[jeffhandley]

This issue title seems to be targeted at .NET 6 and I'm trying to clean up the .NET 6 project. Do we need to update the issue or create a new one?

I defer to @marek-safar on this