Xamarin-macios: Mac Catalyst: should we have Runtime.Arch? If so, what should it return?

[rolfbjarne]

Question:

• What do we do with regards to the Runtime.Arch property for Mac Catalyst?

Possibilities:

1) Remove it.
Con: existing code won't compile / increases binary incompatibility with iOS.
2) Keep it, and return:
2.1) Simulator
2.2) Device
2.3) A third value (MacCatalyst?)

[dalexsoto]

I am thinking the solution should be between 2.2 and 2.3, 1 is definitely a no go for me, I think it would be useful to tell that we are running in the MacCatalyst context but OTOH we are running on a Device, definitely not a simulator heh

My vote would lean to 2.3, MacCatalyst

[spouliot]

A new value, like MacCatalyst, means code changes on every call sites :(

$ git grep Runtime.Arch | wc -l
     170
$ git grep Runtime.Arch | grep SIMULATOR | wc -l
      95
$ git grep Runtime.Arch | grep DEVICE | wc -l
      68

and then it's also used inside generated binding code...

if (Runtime.Arch == Arch.DEVICE) {

but AFAIK it's always (generated) for DEVICE which in fact is more a Intel vs ARM (ABI) decision.

@rolfbjarne were you planning to change the generated code for Catalyst ?

Maybe we could add Intel and Arm with the existing (SIMULATOR and DEVICE respectively) values ?

[rolfbjarne]

were you planning to change the generated code for Catalyst ?

It's easy enough to change the generated code for Catalyst if we wanted to. It shouldn't affect existing binding NuGets for Xamarin.iOS, because those will have to be rebuilt anyway.

A new value, like MacCatalyst, means code changes on every call sites :(

We could do something like this:

public enum Arch {
    DEVICE,
    SIMULATOR,
    MACCATALYST = SIMULATOR,
}

[spouliot]

MACCATALYST = SIMULATOR,

and what will happen when we run this natively on a M1 CPU ?

[rolfbjarne]

Unfortunately Arch.SIMULATOR and Arch.DEVICE has been used with different meanings, which comes back and bites us now 😒

As far as I can tell, some call sites will have to be updated no matter which solution we choose. We'll just have to pick the best poison.

[spouliot]

Indeed, the thing is DEVICE and SIMULATOR are not Arch.

Up to this summer they were based on different architectures so that _worked_ just fine. But it was effectively a case of _badly_ named members (or property).

We'll just have to pick the best poison.

I'd rather not pick a poison 💀. It's ☢️ waste so let's pretend it does not exists.

I suggest we don't add MACCATALYST (of any casing variation). That would only be another step in the wrong direction - it's a dead-end.

Instead let's start a new road where we:

• Obsolete Runtime.Arch and it's SHOOTING enum members
• Add methods/properties to Runtime to
  
  
  
  • give us the ABI, minimally families (Intel vs ARM) and, if needed, down to arm64, arm64e (and I think we might already have some for stret right ?)
  
  
  • tell us if we're running under the simulator, e.g. Runtime.RunningUnderSimulator
  
  
• update the generator to use the correct methods/properties (largely, if not all, ABI related)
• update non-generated source code to use the correct API based on the context, i.e. don't guess the ABI by checking for simulator or device
• update our linker Arch optimizations to map the new API