note: this is not a breaking change (even if it looks like one, even in
API diff) since there is a `[NoMac]` in `d16-8-xm` that was removed (and
never released for XM) in `xcode12`.
This can easily happen when existing type(s) or framework are added to a platform. E.g.
```csharp
[Watch (6,0)][iOS (9,0)]
interface AVFoo {
[Watch (6,0)][iOS (13,0)]
void NewMember ();
}
```
Here we have duplicate attributes and, while not confusing, it does mean extra (and non required) metadata into the platform assemblies.
```csharp
[Watch (6,0)][iOS (9,0)]
interface AVFoo {
[Watch (5,0)][iOS (13,0)]
void NewMember ();
}
```
Here we declare a member as available when the type is not. I'm not sure how the IDE will react - but this should be audited since one of them is wrong (whatever the IDE behaviour is).
Fix https://github.com/xamarin/xamarin-macios/issues/6856
Backport of https://github.com/xamarin/xamarin-macios/pull/9825
Includes additional fixes for XM (disabled in `main`)
* 'GKGameCenterViewController' init throws on macOS 11 and makes sense
to remove the DefaultCtor since it has other init methods that
should be used instead. Added XAMCORE_4_0 removal.
* 'ModelIO' seems to be broken in macOS 11.0, if you touch several
types you end up getting some C++ errors
* 'CoreSpotlight.CSLocalizedString' crashes in Xcode 12.0 GM and now
in Xcode 12.2 Beta 2 on macOS.
Added issues to check for future betas/GM here #9744
* [introspection] Do not let intro check on QTKit now that is just stubs
* Update ApiCtorInitTest.cs
* [QTKit] Fix more QT Tests
* Remove some more QT leftovers
Xamarin.Mac only supports 64 bits - since the supported macOS and
Xcode have dropped 32bits last year.
QTKit headers were removed but we still had bindings code generated
and kept to avoid braking changes.
This is now replaced by stubs, which are a smaller (no code and less
metadata).
```
Current Xamarin.Mac.dll 23,990,784 bytes
QTKit-stubbed XM.dll 23,843,840 bytes
Difference 146,944 bytes
```
reference: https://github.com/xamarin/xamarin-macios/issues/7704
Figure out if
* we're missing enum values (easy to workaround, but annoying for developers)
* we expose enum values that are not defined natively (potential bugs)
reference: https://github.com/xamarin/xamarin-macios/issues/7527
backport of #9691 with additional macOS and xcode12.2 fixes
There are two reasons for this:
* It grants us more independence from the mono archive for .NET 6.
* We need a bugfix in ikvm, but we can't necessarily bump mono.
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
and fixes the ones that have some.
From https://github.com/xamarin/xamarin-macios/issues/9724
We do not _normally_ add availability attributes on enums **members** that represent error codes. In part because it's a lot of metadata and, foremost, because it's not really helpful to write code. E.g.
```csharp
var err = Call.Api (1);
switch (err) {
case NSError.Bad:
case NSError.Wrong:
Console.WriteLine ($"API failed: {err});
break;
case NSError.Ok:
break;
default:
Console.WriteLine ($"Unknown error code {err}");
break;
}
```
Adding version checks inside this would be complicated (source wise) and not really helpful since
* API can return undefined error code (and the error logic should work);
* Availability information is not 100% accurate;
As such we default to not add them - but we some time forgot about it. An intro rule could easily ensure we don't add them needlessly.
We already had support for ObjC API but nothing reported missing
availability attributes for p/invokes, used in manual bindings
Backport of #9700 which adds fixes for missing [Deprecated] inside Xamarin.Mac.dll