Xamarin-macios: [Meta] .NET 6 Support

[chamons]

As previously announced - Xamarin.iOS and Mac are part of the Journey to One .NET that has begun with .NET 5.

Building upon our work initially tracked for .NET 5 Support, we now plan to onboard iOS and macOS in the .NET 6 timeframe.

Our releases will ship with .NET 6 expected to begin previewing late this year and shipping GA in November 2021.

See the .NET Core Roadmap for details.

As we continue, this issue will be updated with additional information.

Target Support Matrix

What capabilities can .NET developers expect to be supported and when?

Some features and capabilities in Xcode are available to developers by virtue of binding iOS. While bindings may make those features available, we may not have documentation, templates, and IDE features to make them easily accessible.

As always our focus will be informed by developer need and demand.

| | Bindings & Tooling | Docs & Samples | Milestone |
| -------------------------------------------------------------------- | ------------------ | ---------------- | ------------------------------------------------------------------------- |
| iOS / iPadOS | In Progress | Planned | .NET 6 Preview 1 |
| macOS | In Progress | Planned | .NET 6 Preview 2 |
| tvOS | In Progress | Planned | |
| watchOS | No | No | |
| Catalyst (iOS on macOS) | Planned | Planned | |

Status Legend

• In Consideration - researching and considering this feature
• Planned- planned to be implemented
• In Progress - actively being worked on
• No - not planned to be supported

Related Dependencies

We are maintaining the .NET bindings that enable developers to access and use the native APIs provided in Xcode 12. In order to be useful we have several cross-product dependencies such as .NET Runtime (Mono), .NET Core, and Visual Studio.

Where is the Code?

All work is being done here in the open, some starting in a branch and landing in main over time. You can follow much of it commit by commit here: https://github.com/xamarin/xamarin-macios/tree/main/dotnet

Feedback

Specific .NET 6 questions can be asked in the comments of this issue or our public discord channel.

Feedback may be directed to the team’s program manager david.[email protected]

[DamianMehers]

Thanks @chamons

FWIW I don't think that supporting WatchOS would be worth it without SwiftUI support in Xamarin by the end of 2021.

More and more new features on both WatchOS and iOS have SwiftUI and Swift dependencies (such as new complications on the watch and WidgetKit and RealityKit on iOS).

I know that the move to .NET 6 must be all-consuming, but I'd be putting a substantial amount of wood behind the arrows of Swift binding support and SwiftUI support, otherwise in a couple of years Xamarin may lose much of its relevance on Apple's platforms, even with Forms/MAUI on top, since a lot of the new stuff, that keeps developers excited and motivated, won't be possible.

[charlesroddie]

Terrible news!

[DamianMehers]

Terrible news!

Why? They have not dropped support for anything ... for me nothing has changed ...

[charlesroddie]

This guts .Net 5, the whole point of which was to unify .Net. Now .Net 5 is really .Net Core 4 and Xamarin devs have to wait a full year longer on mono!

[tvsports86]

Please consider Catalyst! I’ve seen a lot of demand online for this product

[eNeRGy164]

This guts .Net 5, the whole point of which was to unify .Net. Now .Net 5 is really .Net Core 4 and Xamarin devs have to wait a full year longer on mono!

Maybe it is for you personally, But there are more people in the world using .NET Framework and .NET Core without using Xamarin iOS/Android. For them nothing has been gutted from .NET 5 (yet).

[idchlife]

I really hope new features with widgets and catalyst will be available in Xamarin soon. (because I'm a huge fan of Xamarin!)
I love it ❤️ )

Is it even possible - that this will be available approximately in the same time as official release of iOS 14?
I mean many swift developers going to grab betas and develop with new features to obtain more customers and improve their apps businesses, so they will be ready and preapared to pleasantly surprise their users when official iOS 14 will be released.

I sincerely hope that devs and companies using Xamarin won't be way behind in this widgets and watchOS interfaces race which in the end can cost them customers and money.

[dajbych]

Catalyst should be supported as soon as possible. iOS developers will be earning money for their universal apps sooner than UWP developers who built Continuum apps and than switched to Xamarin. How ironic.

[glopesdev]

Any decisions on moving OpenTK types out of platform assemblies for the .NET 6 build? Seems like the perfect opportunity to settle these outstanding issues and make a fresh start: #5275, #5107, #4959, https://github.com/mono/opentk/issues/19.

[chamons]

@glopesdev - It is still in consideration and no decision is final, though internally we're leaning against it (to be transparent here).

It turns out that a LOT of very commonly used types (Vector2, Vector3, Matrix2, Matrix3, Matrix4) are used in many many API bindings (scenekit, spritekit, GameplayKit, ARKit, etc).

$ cd xamarin-macios/src
$ git grep OpenTK | grep using | wc -l
     248

Any rename would be a massive undertaking for consumers of the SDK.

[glopesdev]

Why can't this ship as a separate assembly, versioned separately? The only issue is that it ships with the Core SDK, hence preventing any alternatives. The issue is not renaming the dependency, but that you won't even present it as an option to users.

You do realize this is quite unethical behaviour from an open-source community point of view, right? When you fork, you either change the namespace, or maintain the product.

[glopesdev]

If this is just about math types, what about a compromise? If the OpenTK project would release an OpenTK assembly with just the math types (other functionality is being split away into different assemblies anyway) would you consider switching to the new assembly?

Could we have both projects collaborating as happened in the past?

[chamons]

Let me try to explain the situation we find ourselves in, due to historical reasons, and how it's not easy to resolve with a massive breaking change on our end.

1. Xamarin.iOS ships hundreds and hundreds of APIs with return types or parameters with OpenTK derived types.

Example:

using Vector3 = global::OpenTK.NVector3;

interface SCNLight : SCNAnimatable, SCNTechniqueSupport, NSCopying, NSSecureCoding {
    [Export ("probeExtents", ArgumentSemantic.Assign)]
    Vector3 ProbeExtents { get; set; }
}

1. Our customers have applications using those type in various ways. Some of those customers might not even have the source code to libraries they depend upon at this point.
2. Today those types are in the namespaceglobal::OpenTK from Xamarin.iOS.dll. Even if we used a type forwarder and moved them into a separate assembly, we'd still be stomping over your namespace with types that won't be API compatible.
3. The move to .NET 6 is going to be a breaking change of some sort, but many of them will be binary breaks but not source breaks (meaning the code will need to be recompiled for the new platform, but not changed). There is a big difference between "create a new csproj and make small tweaks" and "do all of that, and now change possibly hundreds of namespaces and variable declarations all over your project".

I hope you can believe me when I say I'm rather unhappy that we're causing folks pain due to our historical decisions here. We're an open source product here, and we're trying to be good citizens as much as we can.

If we can come up with a plan that reduces or removes the namespace pain without causing massive API breakges to our users I'm happy to bring it to the team for consideration. My understanding was the OpenTK devs were working on version fixing at least some of this from their end.

Can you sketch out your proposal in some detail?

[glopesdev]

@chamons Can you confirm that the issue is limited to math types? I am considering some ideas for this, but the proposal might be impacted depending on whether the compromised API surface is restricted to math types or goes beyond it.

[ivanicin]

@DamianMehers @chamons

FWIW I don't think that supporting WatchOS would be worth it without SwiftUI support in Xamarin by the end of 2021.

I really can't fully agree on this one.

There are two sorts of watchOS apps:

1. watchOS-first apps
2. complex cross device apps that have a watchOS form

For the first sort of app what you said is mostly true, but... aside from offering familiar language to some developers there is almost nothing that Xamarin can offer to those developers over XCode and many of those developers will opt for XCode no matter what Xamarin does.

But for the second group, what you asked for would be helpful, but it is much less critical. For example, I have one such app and at the moment i am still in 'wait and see' what Xamarin does. I can port the code to XCode and I have already ported part of the code a long ago, but still... aside from creating maintaining of two code bases will be possibly too complex for me to handle, and while I am sure that time invested in Xamarin app would pay off, I can't be so sure for XCode. And this is the classic example of what Xamarin is about and why it SHOULD support watchOS even if it doesn't support every possible feature of it.

Still I would expect this bug to be resolved: https://github.com/xamarin/xamarin-macios/issues/6244 .

[Mogikan]

Any news regarding "In consideration" features?

[davidortinau]

@Mogikan not at this time. .NET 6 planning will begin in earnest in the coming weeks for the entire product group. I do not anticipate a change in status immediately, but it will be discussed.

[sirmak11]

@davidortinau any news on watchos support ?

[ghost]

@davidortinau any news on watchos support ?

@chamons @rolfbjarne

[jwosty]

I'm willing to help make contributions to help make this happen. I'd love to know where to start when the time comes.

[davidortinau]

The .NET plans for .NET 6 are visible here https://themesof.net/. Work in .NET 6 across runtime, SDK, and tooling to support watchOS did not make the cut.

[DamianMehers]

The .NET plans for .NET 6 are visible here https://themesof.net/. Work in .NET 6 across runtime, SDK, and tooling to support watchOS did not make the cut.

@davidortinau could you clarify if this means that we should not ever count on watchOS support for .NET going forward, or is it a question of more immediate priorities.

Basically I'd like to know if I should be rewriting my app in Swift, or is C# on watchOS likely to make it eventually. My watch app isn't an adjunct to a phone app, so a rewrite would be a substantial amount of work and I'd lose the ability to share my business logic across Tizen, Android, wearos, iOS, macOS, windows and Xbox as I do now. I'd probably just focus on Apple's platforms and move on from .NET for this app at least.

I appreciate these kinds of decisions are not easy. I just need clarity as to whether there is hope for .NET on watchOS.

Thanks,
Damian

[chucker]

Will Xamarin still support the legacy Mono SDK/runtime for watchOS, or will this break Xamarin for watchOS for the foreseeable future?

[davidortinau]

@DamianMehers it's absolutely a matter of prioritization. We've had some hard decisions about where we should focus. The transition to .NET 6 is a big effort with big rewards, so this isn't a typical Xcode/iOS version bump.

I can't speak to what we may do after .NET 6. At that time we'll re-evaluate. It'll get a fair shake. I wouldn't expect any change in this plan until we ship .NET 6, and even then it wouldn't be an insignificant amount of time before anything would be available. (Yes, I used a lot of negatives.)

@chucker existing watchOS still works and can be expected to continue as-is. We are not removing what's there now. There are known aspects of the development experience with it that due again to prioritization we've not addressed.

[Csaba8472]

@davidortinau please correct me if I'm wrong, to sum it up, we can/could have WatchOS support with xamarin in four ways:
1, with existing as-is WatchOS support (business logic and ui written in c#/xaml)
2, with existing AdditionalAppExtensions (https://github.com/xamarin/xamarin-macios/issues/10070) (business logic and UI written in swift/swiftui)
3, with embeddinator4k we could share c# business logic, but we still need 2) and to create UI with SwiftUI (https://github.com/mono/Embeddinator-4000/issues/657 this is not there yet)
4, with the all-we-could-ask-for WatchOS support which wraps SwiftUI, watch app would be able to use all latest, greatest feature with c#(this is not planned currently)

I think now as 1) is as-is and SwiftUI is more feature-rich than storyboard based layouts, going with 2) is the preferable way. Having 3) would be even better, is there a plan to support WatchOS?

[NogginBops]

Has the OpenTK namespace incompatibility been given any thought? (if not, this is a ping for that issue 🙂)