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?)

---

Time estimate (for Sebastien's proposal here): 4 weeks

[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

[rolfbjarne]

Downgrading priority since the current solution works (although it's ugly), and we can implement this at a later stage (we're not going to add any breaking changes either now or later anyway).

[rolfbjarne]

Downgrading priority since the current solution works (although it's ugly), and we can implement this at a later stage (we're not going to add any breaking changes either now or later anyway).

Now that we've decided to do breaking changes for .NET 6, and Mac Catalyst binaries won't be compatible with iOS binaries anymore, I think we can reconsider this and just remove the Runtime.Arch API for Mac Catalyst.