iOS Compatibility with other Firebase plugins or binding libraries

[AdamEssenmacher]

It looks like version 4 of Shiny will be introducing its own slim binding dependencies Shiny.Firebase.Analytics.iOS.Binding and Shiny.Firebase.Messaging.iOS.Binding as replacements for the abandoned Xamarin/Microsoft-published binding packages Xamarin.Firebase.iOS.Core and Xamarin.Firebase.iOS.CloudMessaging.

It seems that the Shiny.Firebase.*.iOS.Binding nugets are packed in such a way that common Firebase XCFramework dependencies (e.g. FirebaseCore, FirebaseAnalytics, FIrebaseInstallations, nanopb, etc.) are built into intermediate XCFrameworks ShinyFirebaseAnalytics.xcframework and ShinyFirebaseMessaging.xcframework that statically link the Firebase dependencies.

Do we expect that these Shiny.Firebase.* packages would be compatible with other nuget packages that also include these common Firebase dependencies? More concretely, do we expect that these packages will be compatible with libraries like Plugin.Firebase or BarcodeScanner.Mobile.Maui?

I'm concerned that the answer right now would be 'no'. I would think that two or more nugets delivering the same statically linked libraries are bound to cause problems such as symbol conflicts, build warnings/errors, and/or runtime issues.

I voiced this concern a few months ago in a MAUI discussion:

Google and Firebase libraries often have shared native dependencies, which means a slim binding nuget packed for Firbase Messaging is going to have a real hard time getting along with a separate slim nuget packed for Firebase Analytics. This is why we have the Firebase.Core artifact right now, for example.

Even in a world where responsibility for all API binding development is distributed to various community / OSS projects, we still need a central, trusted, and reliable publisher of common native library sdk dependencies.

I also opened a related issue in the slim bindings demo project that @aritchie helped develop, where @aritchie replied:

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).

As a quick test, I imported Shiny.Firebase.iOS.Messaging.Binding package into a MAUI project that is currently using Plugin.Firebase. I was able to build and deploy it to a physical device without any problems, but immediately ran into Firebase errors crashing the app at run time.

So, my questions:

Is my understanding of this situation correct? Would a project referencing Shiny.Firebase.Analytics.iOS.Binding be fundamentally incompatible with any other library / nuget that also contains common Firebase dependencies?

If my understanding is correct, should Shiny consider pivoting to use AdamE.Firebase.iOS.* to maintain compatibility with other iOS.NET Firebase libraries?

If my understanding is incorrect, what (if anything) should Firebase plugin maintainers do to make sure our nugets are compatible?

[aritchie]

Please save the summarization in the future. I was there for all of it.

If my understanding is correct, should Shiny consider pivoting to use dotnet/maui#20359 (comment) to maintain compatibility with other iOS.NET Firebase libraries?

Should - No. Could - yes. Will - Not right now. For many reasons.

1. Maintainers come & go. I want something that I can be sure satisfies the customers I have. Having my own bindings ensures that and puts things on my release schedule now.
2. The only library that takes an iOS dependency on Firebase is the push provider, nothing else.
3. If users need a bunch of other firebase services, they're better off taking a reference on Plugin.Firebase
4. If users need a split, Shiny offers a IPushProvider abstraction to allow you to build on any additional library you may use. They are welcome to build and support your own push provider if you want.
5. I don't use Firebase on iOS personally, so this is something that I support for my sponsors & customers only
6. If your library becomes the "standard" in the community and I see enough traffic on firebase messaging, absolutely, I will consider it at that time.

[AdamEssenmacher]

Please save the summarization in the future. I was there for all of it.

The summary wasn't for you. It was for your customers (and mine) to give them context around the history of the issue.

Your answers make total sense. I'll add some documentation in my bindings fork and Plugin.Firebase to warn about the incompatibility.

It's worth mentioning that this incompatibility might be larger in scope than just Firebase. Other popular Google-owned SDKs might be affected as well (e.g. Maps, SignIn, Analytics, MLKit).

Thanks for the response. I don't use Shiny personally, this is just something that I'm supporting for the community.