Add new RID for Catalyst

[marek-safar]

We need to introduce new Catalyst RIDs to be able to build Catalyst runtime packs. I propose we add the following new RIDs to support them inheriting from iOS RID.

maccatalyst-arm64
maccatalyst-arm64-13
maccatalyst-arm64-14
maccatalyst-x64
maccatalyst-x64-13
maccatalyst-x64-14

I went with a simple catalyst instead of macOSCatalyst as it's very long and it runs on iPadOS as well.

@steveisok @terrajobst

[dotnet-issue-labeler]

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.

[akoeplinger]

I went with a simple catalyst instead of macOSCatalyst as it's very long and it runs on iPadOS as well.

That's not the case, a Catalyst app doesn't run on iPadOS, it just supports the same APIs running on macOS and is usually used to port iPad apps to the Mac.

The official name is Mac Catalyst (see https://developer.apple.com/documentation/xcode/creating_a_mac_version_of_your_ipad_app) so I wonder if we should call the RID maccatalyst. I don't feel strongly though.

[steveisok]

The problem with maccatalyst is that it's too long. That said, I do like it better.

[bramborman]

While longer, it clearly states that it belongs to the Apple/Mac ecosystem. The shorter catalyst may be harder to categorize for devs not familiar with Apple.

[marek-safar]

I think maccatalyst would work too but it'd be the longest rid to have. All the existing names are much shorted (e.g. sles, tvos, ol, etc).

[steveisok]

What about maccat to keep it short?

[ericstj]

a Catalyst app doesn't run on iPadOS, it just supports the same APIs running on macOS and is usually used to port iPad apps to the Mac.

In that case, should this derive from OSX instead of Unix? We have a few places where we build a configuration of a library for OSX. Here's a couple:
https://github.com/dotnet/runtime/blob/b37f10a504f20faef2558b6d79180411ad0603c3/src/libraries/System.Security.Cryptography.X509Certificates/src/System.Security.Cryptography.X509Certificates.csproj
https://github.com/dotnet/runtime/blob/c58e45c9bfe63e0e6dc950eb9242507cb53841df/src/libraries/System.IO.FileSystem.Watcher/src/System.IO.FileSystem.Watcher.csproj

It sounds like we're going to need to artificially cross-compile these now in order to deliver the right implementation on catalyst. I can imagine customer code which pinvokes to platform API needing to do the same.

[directhex]

Catalyst is, at least from a build perspective, the iOS API running on macOS libraries. So, random example, the system system call exists in macOS but will cause a compile time error if you enable Catalyst (which you basically do by adding a -target x86_64-apple-ios13.2-macabi flag to the compiler/linker, which is mutually exclusive with a -mmacosx-version-min flag)

The compiler triple implies it derives from iOS not macOS, in Apple's mind.

[akoeplinger]

What we do at the RID level and what we do in the libraries build are two different scenarios: the RID is mostly concerned about native binary compatibility: in that case as @directhex mentioned it's a new ABI so there's no compatibility with existing binaries - hence deriving from unix for the RID is the right call.

For the libraries build we can mostly share the managed implementations, that's what we already do e.g. by adding '$(TargetsiOS)' == 'true' in

runtime/src/libraries/System.Security.Cryptography.X509Certificates/src/System.Security.Cryptography.X509Certificates.csproj

Line 394 in b37f10a

<ItemGroup Condition=" ('$(TargetsOSX)' == 'true' or '$(TargetsiOS)' == 'true' or '$(TargetstvOS)' == 'true') and '$(IsPartialFacadeAssembly)' != 'true'">

[steveisok]

So... what should we call it? maccat or maccatalyst?

[akoeplinger]

Given the design proposal for the TFM is net6.0-maccatalyst (dotnet/designs#174) I'd prefer maccatalyst as the RID name so we're consistent.

[marek-safar]

My feeling is that I'd choose maccat for exactly that reason :-) to make it clear that maccatalyst TFM serves a different purpose and it's not needed for maccat

@ericstj any thoughts on the naming?

[akoeplinger]

to make it clear that maccatalyst TFM serves a different purpose and it's not needed for maccat

I think from an end-user point of view the purpose is the same ("I want to target Mac Catalyst with managed/native assets") so I don't think we should make a distinction there.

[ericstj]

Catalyst is, at least from a build perspective, the iOS API running on macOS libraries.

I see, I had that backwards. In that case should it derive from the iOS RID?

the RID is mostly concerned about native binary compatibility

It is not. It's meant for both native binaries and assemblies. It's meant to model both platform API and native binary compatibility, to allow as much asset reuse as possible. RID hierarchy is entirely pragmatic: it's whatever we find most useful. The one thing it must be is internal; RID's cannot influence compile time behavior, so they cannot be used to model platform specific public API. That's where the TFM (and TFM+TPM) is different, since that's specifically about exposing and extending platform specific public API.

@ericstj any thoughts on the naming?

I know we regretted using win instead of windows. For more recent RID additions we've tried to avoid abbreviations, especially homegrown ones. I tried searching for both maccatalyst vs maccat. The former had a bunch of relevant results, the latter gave me information on a particular model of chainsaw.

I don't think we need to care too much about confusion between RID and TPM. Folks are going to confuse those regardless of the values. Context is what matters there. cc @terrajobst

[akoeplinger]

the RID is mostly concerned about native binary compatibility

It is not. It's meant for both native binaries and assemblies. It's meant to model both platform API and native binary compatibility, to allow as much asset reuse as possible.

Sure but it seems to be rare to use it for managed RID-specific assets, more common are native binaries. The only matches for the former I have in my NuGet packages cache are Microsoft.* and System.* ones :)

If NuGet authors are mainly using it for native binaries then it'd probably make sense to not derive maccatalyst from ios since the native ABI isn't compatible.

[directhex]

the RID is mostly concerned about native binary compatibility

It is not. It's meant for both native binaries and assemblies. It's meant to model both platform API and native binary compatibility, to allow as much asset reuse as possible.

Sure but it seems to be rare to use it for managed RID-specific assets, more common are native binaries. The only matches for the former I have in my NuGet packages cache are Microsoft.* and System.* ones :)

If NuGet authors are mainly using it for native binaries then it'd probably make sense to not derive maccatalyst from ios since the native ABI isn't compatible.

What about the mobile case? Surely Catalyst can consume iOS managed nugets? Aren't there a whole bunch of Xamarin components out there?

[akoeplinger]

The existing Xamarin.iOS nugets don't use the RID setup so they'd be pulled in because of the compatibility mappings that will be defined as part of dotnet/designs#174

[steveisok]

If NuGet authors are mainly using it for native binaries then it'd probably make sense to not derive maccatalyst from ios since the native ABI isn't compatible.

Yeah, I think it makes sense to derive from unix then.

[ericstj]

Sure but it seems to be rare to use it for managed RID-specific assets, more common are native binaries. The only matches for the former I have in my NuGet packages cache are Microsoft.* and System.*

You can use Kusto to do a more scientific query. We shouldn't discount our own packages. Those packages are going to grow because of this with a redundant copy of the binary.

If NuGet authors are mainly using it for native binaries then it'd probably make sense to not derive maccatalyst from ios since the native ABI isn't compatible.

Yeah, I think it makes sense to derive from unix then.

Native binaries work with either parenting, since maccatalyst will be more specific. Managed binary reuse only works if you parent from iOS.

[ericstj]

Just to restate the tradeoff here:

1. Parenting to unix:

• Pro: failure behavior of ios package is file not found.
• Con: Packages which build ios runtime specific binaries will need to duplicate assets.

2. Parenting to ios :

• Pro: binary reuse of managed ios assemblies.
• Con: failure behavior with an ios package is some form of load failure.

IMHO option 2 enables a scenario without really losing anything meaningful. We also have precedent for this in linux-musl deriving from linux.

[steveisok]

@ericstj Thanks for breaking it down like that. It doesn't seem like there's harm in deriving from ios.