[Announcement] Breaking changes in .NET 6 for iOS, tvOS and macOS

[rolfbjarne]

In order to fully support the new native types in C# (nint, nuint), we’ve unfortunately realized that we can’t keep compatibility with existing code or assemblies built for Xamarin.iOS or Xamarin.Mac.

The consequences are as follows when upgrading a project to .NET 6:

1. All code must be recompiled to support .NET 6. Existing assemblies (such as NuGets built for the old TargetFrameworkIdentifier xamarinios10) won’t work and won’t be supported. Non-xamarin specific assets for net4.x, netstandard, netcoreapp, net5.0+, etc. will work fine however.
2. Existing code might need to be modified. We’ll post a more detailed document with examples of code changes that might be required at a later point.

In addition, we’re taking the opportunity to fix a few mistakes we’ve made in the past, that we’ve been unable able to address because they were breaking changes.

These are the main changes:

1. Removal of the System.nint and System.nuint types. We’re going to use the nint and nuint types as defined by C# (they are System.IntPtr and System.UIntPtr under the hood).
2. Removal of the System.nfloat type. We're going to use the System.Runtime.InteropServices.NFloat type instead. For the System.nfloat type we’re probably going to keep the type [1], but move it to a different namespace.
3. Use a different type than System.IntPtr for handles (the NSObject.Handle property): ObjCRuntime.NativeHandle. This is to avoid confusion between nint/nuint and handles.
4. Move all the types in the OpenTK namespace elsewhere.

We also have a list of minor changes we’ve wanted to do for a long time: #5107. We’ll be going through this list and implement the ones that make sense and that we have time to complete.

The first preview with these breaking changes will be Preview 11.

Reference: #10508
Reference: dotnet/designs#252
Reference: NuGet/Home#11338

[1]: System.Runtime.InteropServices.NFloat is not a good replacement for System.nfloat, because it’s a very basic type intended only for interop scenarios. For instance, it does not have any operators, so code like “NFloat + NFloat” does not compile. The operators were implemented and back ported to .NET 6, so the concerns with System.Runtime.InteropServices.NFloat went away.

[marek-safar]

This also means that we should change precedence rules for net6-ios/tvos/macos TFMs as were designed in https://github.com/dotnet/designs/blob/main/accepted/2021/net6.0-tfms/net6.0-tfms.md.

/cc @mhutch

[rolfbjarne]

@marek-safar I have a PR for that: dotnet/designs#252

[mattleibow]

If NFloat is missing things, maybe operators should be added to that? What other features need to be added to that to make it work?

Not sure if it is going to have a weird scenario next year where half the stuff is xamarin nfloat and the other is dotnet nfloat.

[jkotas]

Can nfloat be replace with double in the public surface to keep things simple? nfloat does not have much advantage anymore now that almost all Apple devices are 64-bit.

[NogginBops]

This is the time to finally fix the OpenTK issue!
You are doing a binary breaking change here which was the only reason stated for why the OpenTK assembly types where not completely removed from Xamarin when this issue was raised before.
This has been an issue for more than 6 years and it would be soooooo good to finally have it fixed.
It's in the list from #5107 as Move OpenTK types out of platform assemblies.

[Perksey]

Thanks for this. To clarify for those unfamiliar with the Xamarin project planning/schedule, where on the .NET 6 shipping schedule does Xamarin "Preview 11" fall?

[Perksey]

@NogginBops I believe this is point 3 in the issue description?