Repository navigation
Add new RID for Catalyst #47518
Description
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.
Activity
Add Mac Catalyst RIDs
akoeplinger commentedon Jan 31, 2021
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 RIDmaccatalyst. I don't feel strongly though.steveisok commentedon Jan 31, 2021
The problem with
maccatalystis that it's too long. That said, I do like it better.bramborman commentedon Jan 31, 2021
While longer, it clearly states that it belongs to the Apple/Mac ecosystem. The shorter
catalystmay be harder to categorize for devs not familiar with Apple.marek-safar commentedon Feb 1, 2021
I think
maccatalystwould 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 commentedon Feb 1, 2021
What about
maccatto keep it short?ericstj commentedon Feb 1, 2021
In that case, should this derive from
OSXinstead ofUnix? 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.
5 remaining items
akoeplinger commentedon Feb 2, 2021
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 commentedon Feb 2, 2021
I see, I had that backwards. In that case should it derive from the iOS RID?
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.
I know we regretted using
wininstead ofwindows. For more recent RID additions we've tried to avoid abbreviations, especially homegrown ones. I tried searching for bothmaccatalystvsmaccat. 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 commentedon Feb 2, 2021
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.*andSystem.*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 commentedon Feb 2, 2021
What about the mobile case? Surely Catalyst can consume iOS managed nugets? Aren't there a whole bunch of Xamarin components out there?
akoeplinger commentedon Feb 2, 2021
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 commentedon Feb 2, 2021
Yeah, I think it makes sense to derive from unix then.
ericstj commentedon Feb 2, 2021
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.
Native binaries work with either parenting, since
maccatalystwill be more specific. Managed binary reuse only works if you parent from iOS.ericstj commentedon Feb 3, 2021
Just to restate the tradeoff here:
unix:iospackage is file not found.iosruntime specific binaries will need to duplicate assets.ios:iosassemblies.iospackage 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-muslderiving fromlinux.steveisok commentedon Feb 3, 2021
@ericstj Thanks for breaking it down like that. It doesn't seem like there's harm in deriving from
ios.Add Mac Catalyst RIDs (#47645)