search

CommunityToolkit / Maui.NativeLibraryInterop

Maui.NativeLibraryInterop is a community-created library of binding samples to help .NET MAUI developers interop with native libraries more easily
MIT License
159 stars 24 forks source link

iOS native dependency management #6

Closed AdamEssenmacher closed 5 months ago

AdamEssenmacher commented 5 months ago

Following this project's example, let's say I want to create and distribute an iOS.NET library for Google-Mobile-Ads-SDK. This has the following native dependencies:

Then, say a different developer creates and distributes an iOS.NET library for FirebaseFirestore. That has dependencies:

Please correct me if I'm wrong, but wouldn't there be a major linking issue if both of these theoretical iOS.NET packages embedded their xcframework dependencies? In this example, nanopb, GoogleUtilities, and PromisesObjc are shared.

In the examples currently published (Firebase messaging and analytics), the analytics library appears to be getting used as a 'dumping ground' for the shared dependencies, with the messaging library not including these as native dependencies, but instead referencing the analytics csproj.

aritchie commented 5 months ago

The analytics library is considered core basically with what google is doing. We also didn't want to create different libraries/packages for every single sub-dependency because it will be too much to manage even if this does move to some form of community project.

You are correct there could be linking issues if another outside libraries ref different packages. This is why nothing has been pushed to nuget (and may not be at all). We can't solve all issues, but this shows relatively how easy binding native libraries can be done, so people can help themselves before the Firebase Messaging deadlines.

AdamEssenmacher commented 5 months ago

The analytics library is considered core basically with what google is doing.

I was really hoping to see improvement in this area. This approach (which is what FIrebase.Core does now) forces apps to take a dependency on Analytics in cases where you might really just need PromisesObjc (as a contrived example).

We also didn't want to create different libraries/packages for every single sub-dependency because it will be too much to manage even if this does move to some form of community project.

This is exactly what the Android side is doing, and has been doing for years with what appears to be the part-time attention of a single developer. This approach seems to be more maintainable over time since dependency management is reduced to a (relatively) simple version mapping task.

This is why nothing has been pushed to nuget (and may not be at all).

This really isn't good. You're describing a future where all published iOS.NET libraries with any Google/Firebase dependencies would be incompatible with each other.

so people can help themselves before the Firebase Messaging deadlines.

I'm sure this is appreciated, but the path of least resistance for anyone in this situation right now would just be to use my fork.

Feel free to close this issue, or convert it to a discussion if you'd rather.

aritchie commented 5 months ago

This is exactly what the Android side is doing, and has been doing for years with what appears to be the part-time attention of a single developer. This approach seems to be more maintainable over time since dependency management is reduced to a (relatively) simple version mapping task.

There is more involved than you probably realize here. In any case, there is just two of us right now, doing this in our free time to try to close a gap that exists.

This really isn't good. You're describing a future where all published iOS.NET libraries with any Google/Firebase dependencies would be incompatible with each other.

Again... we're just closing a gap, not solving every single problem. You can clearly see that Microsoft isn't going to put resources here, so instead of complaining about it... we decided to try to do something about it. This isn't a sponsored project. There is no problem with incompatibility. We're simply trying to find ways to make binding easier while providing some much needed bindings for the community. They can also take the patterns here and apply them to accomplish other bindings.

I'm sure this is appreciated, but the path of least resistance for anyone in this situation right now would just be to use my fork.

Then do it. No one is stopping you. If you think you've got a better answer and you want to support it going forward, all the power to you.

Feel free to close this issue, or convert it to a discussion if you'd rather.

We're happy to listen and discuss, but you need to dial it down a notch. There is a enough bile in that MAUI thread. We aren't here for that. We're just trying to help.