Update to .NET 8 baseline

[bengavin]

Given that .NET 6 is now out of support, would it make sense to update the project to target NET 8 as the baseline non-Xamarin version?

[AdamEssenmacher]

The last significant contribution from Microsoft to this project was transitioning it to use the Xamarin.Legacy.Sdk project SDK, which enables targeting both legacy xamarin.ios10 and net6.0-ios. To my knowledge, this SDK does not support .NET 7+.

I am committed to maintaining compatibility with Xamarin until the App Store stops accepting Xamarin apps (likely around April 2025). For full transparency, my personal project— the reason this continuation project exists— is still on Xamarin and will likely stay that way until then. Unfortunately, MAUI 6, 7, and 8 have not been production-ready due to persistent memory issues.

Post-April 2025, this repository will need to migrate off the Xamarin.Legacy.Sdk project SDK as a first step toward supporting .NET 7+. While I estimate this migration would take 1-2 days, unexpected challenges could arise.

Afterward, adding .NET 7, 8, and 9 as target frameworks should be relatively straightforward. I see no reason to drop .NET 6 unless it becomes problematic.

For now, I see no harm in continuing with the .NET 6 target. It remains backward-compatible with .NET 7, 8, and 9. To my knowledge, there are no significant benefits to targeting higher frameworks for iOS binding projects. However, if anyone can point out a tangible advantage and is interested in contributing to the upgrade effort, I’d be happy to move Xamarin-compatible builds to a secondary branch.

@bengavin would you be willing to contribute to the upgrade effort? I'd be happy help getting started on the upgrade now in a parallel branch.

[bengavin]

Yes, I'll likely want to explore down this path once I have some projects targeting .NET 9. Are we considering a package restructuring as part of that move?

[AdamEssenmacher]

Are we considering a package restructuring as part of that move?

I really prefer to publish changes as incrementally as possible. That way, if something goes wrong, the cause is easier to track down. So, if we're going to restructure packages, I'd rather just do that separately.

What do you mean by 'restructuring'? It would solve a lot of problems if Firebase.Core was broken up, with new nugets published 1:1 per pod.

[bengavin]

Yes, that's what I was suggesting, essentially breaking the current packages apart that reference > 1 xcframework [for the most part].

[AdamEssenmacher]

Ok, your PR and this whole situation are making me think now would be a good time to start breaking out dependencies. The current setup could be better.

As a first step, getting to a state where MLKit doesn't depend on Firebase.Core anymore would make sense.

MLKit.Core currently uses Firebase.Core to import:

• GTMSessionFetcher
• GoogleDataTransport
• GoogleUtilities
• PromiesObjC
• nanopb

If we split these five dependencies into their own Nugets, both MLKit.Core and Firebase.Core could import them independently and still be compatible with each other.

Then, your PR could be split up / focused on the MLKit bits you care about right now (and can actually test), leaving Firebase 11 updates for a future task.

[bengavin]

Sounds good, I'll take a crack at including that update with my latest PR