Best maintenance strategy for native Auth providers (e.g. Facebook)

[Kapusch]

Hi @AdamEssenmacher ,

Following your recent PR for Plugin.Firebase v4, I followed your advice below:

This plugin remains compatible with all of these auth providers, but it is now the responsibility of developers to implement specific provider implementations.

Hence, I implemented my own native wrapper abstractions for iOS (Swift) and Android (Kotlin) for Facebook following these references:

• MS Doc
• GitHub repo samples
  Note: I didn't use Objective-Sharpie

After I did the plumbing into my app, everything finally worked well... but I noticed this warning which scared me a bit:

objc[10782]: Class FBLPromise is implemented in both /something/my.app/Frameworks/FBLPromises.framework/FBLPromises (0x1056a6230) and /something/my.app/something-else (0x104da2a88). This may cause spurious casting failures and mysterious crashes. One of the duplicates must be removed or renamed.

If I got it well, this may be because Plugin.Firebase provides the native classes into my app aside from my own native classes. Hence, realised the FBLPromises.xcframework is actually referenced in this repo in Google project:

GoogleApisForiOSComponents/source/Google/PromisesObjC/PromisesObjC.csproj

Lines 38 to 44 in 3ebe4e6

	<ItemGroup>
	<NativeReference Include="..\..\..\externals\FBLPromises.xcframework">
	<Kind>Framework</Kind>
	<SmartLink>True</SmartLink>
	<ForceLoad>True</ForceLoad>
	</NativeReference>
	</ItemGroup>

Do you think this can be the root cause of my warning? And this is intentional to keep this .xcframework here although there is no native binding to Facebook SDKs? (as per my observation)

cc: @vhugogarcia , @Digifais who recently discussed in this repo and that I consider potential active contributors.

[Kapusch]

Also, I would like to target recent SDK version for Google Sign In (v9 vs v5 in this repo), what would you recommend please?
I assume I would encounter similar warning, so I wonder if I could fork and "break" the current implementation for Google Sign In with my own native wrapper abstractions for iOS (Swift)?

I would need soon to progress on this and I'm bit mixed between:

1. fork this repo only, do the changes, wait for the review and possibly face rejection (which I would understand as my implementation may not satisfy all your expectations)
2. or fork both this repo and Plugin.Firebase, do the changes, and publish my own NuGets
3. or even find a way to unplug the Auth part from the Plugin.Firebase and compensate with my own implementation

Any advice would be appreciated here, but if you prefer, we could also start private chats on this or possibly have a call if better? (Which can be difficult as this is extra activity for you, and it is actually same situation for me) In case you'd like to reach out, please check my profile. As usual, thanks for your support!

[AdamEssenmacher]

In my other response, I described how the old Microsoft package Xamarin.Firebase.iOS.Core was a 'dependency soup'. The AdamE.* bindings are a continuation of this, and so still carry some of this.

However, I've been doing some work to begin improving the situation, breaking some common dependencies out of the Firebase.Core and into their own NuGets. I prioritized the packages that were shared by Maps, Places, SignIn, and MLKit, so those are no longer dependent on Firebase.Core.

With that context, here are my thoughts on your proposals:

fork this repo only, do the changes, wait for the review and possibly face rejection (which I would understand as my implementation may not satisfy all your expectations)

This is the most desirable approach (minus the rejection part). The current version of Sign In published by this repo is version 7 (where did you get 5?). Getting to 9 takes us through two major version bumps. Binding through these can vary wildly in difficulty, depending on the scale and scope of the changes. If you want to go down this path, I'll offer guidance and support.

To be clear though, this would not involve a shim swift wrapper--we'd simply be updating the current implementation.

or fork both this repo and Plugin.Firebase, do the changes, and publish my own NuGets

If you just wanted to write a shim/wrapper for Google SignIn, I don't think you'd need to fork either this repo or Plugin.Firebase. Like with your Facebook shim, you would just want to make sure that shared xcframework dependencies (like FBLPromises) are resolved via PackageReference to the appropriate AdamE.* nugets instead of including them directly.

or even find a way to unplug the Auth part from the Plugin.Firebase and compensate with my own implementation

Plugin.Firebase is already (optionally) delivered in individual components, so you can use other pieces of Plugin.Firebase without Plugin.Firebase.Auth. You're free to write your own platform auth code without using Plugin.Firebase.Auth--the rest of Plugin.Firebase should work just fine alongside.

[AdamEssenmacher]

First, kudos on getting this far—especially on both platforms. If you do get this working, I’m confident others would be interested in using your implementation as a reference. We could certainly update the README to link to a public repo if you’re willing to share one.

Regarding your immediate problem: your analysis is correct. It may appear to work just fine, but that’s a dangerous warning to ignore.

What you’ve run into is a problem as old as Xamarin itself (even predating Forms): packaging and distributing native platform dependencies.

---

The Core Problem (by Analogy)

Consider a regular .net10 project that needs System.Text.Json. You could grab System.Text.Json.dll and reference it directly, but we all know that’s a bad idea. The correct approach is to add a PackageReference to the System.Text.Json NuGet package. That way, if multiple dependencies rely on System.Text.Json, NuGet resolves a single version and ensures only one DLL is included in the final application.

---

Android: When the Model Works

Now consider a .net10-android project that needs Google Play Services. Google Play Services is actually a collection of many native binaries, each with their own transitive dependencies.

If you inspect [Xamarin.GooglePlayServices.Base](https://www.nuget.org/packages/Xamarin.GooglePlayServices.Base), you’ll see that it is a shared dependency of things like Google Maps and Firebase Messaging. It also pulls in common AndroidX libraries that MAUI itself depends on.

This works because Microsoft publishes and maintains 1:1 mirror artifacts for nearly all common Google and AndroidX native libraries. Each native Maven artifact maps cleanly to a NuGet package, and dependency resolution behaves predictably.

---

Android: When the Model Breaks

Now imagine you want to add support for [Facebook Login](https://mvnrepository.com/artifact/com.facebook.android/facebook-login/18.1.3/dependencies).

Microsoft used to publish 1:1 binding packages for the Facebook Android SDK, but those were eventually abandoned. So if you’re creating a binding package for Facebook Login today, you must ensure that its native dependencies—namely facebook-core and facebook-common—are included.

The most straightforward way to do this (and what most developers do) is to add the native .aar files directly to the project. Unfortunately, this approach introduces a subtle but serious problem.

Now imagine a different developer publishes a binding package for [Facebook Share](https://mvnrepository.com/artifact/com.facebook.android/facebook-share/18.1.3/dependencies), which also depends on facebook-core and facebook-common. If a consumer references both packages, they now have duplicate copies of the same native libraries.

---

The “Right” Solution (That We Don’t Have)

The correct architectural solution is to publish canonical, shared NuGet packages for common dependencies:

• Facebook.Android.Core
• Facebook.Android.Common

Then higher-level packages like Facebook.Android.Login and Facebook.Android.Share would each contain only their own native .aar, relying on NuGet to resolve shared dependencies.

The problem is that we don’t have a canonical source for these packages. Outside of the AndroidX / Google ecosystem that Microsoft maintains, most Maven artifacts have no official NuGet equivalents.

As a result, authors of native binding packages are forced into one of two choices:

1. Be incompatible with each other
2. Coordinate around a community standard for shared dependencies

---

iOS: Same Problem, Plus Two More

On iOS, we have the same core problem—but with two additional complications.

1. No Microsoft-Maintained Bindings Anymore

Microsoft no longer maintains binding packages for Google or Firebase iOS dependencies. This is precisely why the AdamE.* packages exist: to act as a canonical, community-maintained standard.

2. No 1:1 Mapping (Historically)

Even when Microsoft did maintain these bindings, they did not follow a 1:1 native artifact → NuGet package model. Instead, they bundled every potentially shared Google dependency into a single “dependency soup” package called:

Xamarin.Firebase.iOS.Core

Google Maps, Sign-In, MLKit, and others each needed some of these dependencies, so they all took a dependency on Xamarin.Firebase.iOS.Core to remain compatible with one another.

---

Where FBLPromises.xcframework Fits In

FBLPromises.xcframework is one of those shared dependencies. It’s used by MLKit, Google Sign-In, and Firebase.

I don’t think it’s a dependency of any Facebook SDKs—but if it were, you’d need to resolve it via a reference to the appropriate AdamE.* NuGet package. That’s the only way to remain compatible with projects that also depend on other Google or Firebase libraries.

---

What’s Likely Happening in Your Case

I can’t see your native iOS wrapper implementation, but my guess is that you’re including Firebase framework(s) alongside the Facebook SDKs. If so, you’re almost certainly pulling in one or more shared frameworks twice, which would explain the behavior you’re seeing.

---

Options for Fixing This

Here are a few viable paths forward:

1. Create a standard iOS binding library for the Facebook SDKs, rather than following Microsoft’s half-baked “slim binding” guidance. If the Facebook SDKs truly have no overlap with Firebase / Google dependencies, this approach should be safe. I’ve done this before for the Facebook Share SDK, and this is the route I took.

2. Refactor your iOS binding project to avoid importing any conflicting libraries, even transitively.

3. Strip duplicate framework dependencies from the wrapper-produced framework, ensuring that shared native frameworks are resolved from NuGet instead of being embedded multiple times.

---

(1) is probably the most ideal, but also probably the most effort. (2) is probably the most straightforward, assuming I'm right about how your binding project is structured. I'm not sure how (3) would look, since I've never created one of those wrappers myself. Maybe it's as easy as deleting some .xcframeworks from a directory--idk.

[Kapusch]

Thanks a lot Adam, your (quick!) answer will help me to progress on this. Just I need time to get on back on it.

However I have 2 doubts to clarify with myself :

• what benefits exactly standard binding has compared to slim binding? And so, should I stop to implement in Swift and Kotlin ?
• also, even if I fix the resolution of reference by using the right AdamE.*, I may face an incompatibility between the SDK version that I'm targeting vs what is actually there in the AdamE.*, am I right?

[AdamEssenmacher]

what benefits exactly standard binding has compared to slim binding? And so, should I stop to implement in Swift and Kotlin ?

Slim bindings just don't really provide any benefits for general-purpose bindings like those provided in this repo. Mapping nearly 100% of the native API surfaces is the goal, and we want the C# API to match as closely as possible so that native API documentation doesn't need to be augmented. If we were to switch to a 'slim' biding approach with these two things in mind, we'd end up doing a lot of the same work with extra steps in between.

Also, 'slim bindings' do nothing to address the complexities of dependency management.

even if I fix the resolution of reference by using the right AdamE., I may face an incompatibility between the SDK version that I'm targeting vs what is actually there in the AdamE., am I right?

I'm not sure I understand your question entirely. If the dependency you need is packed into the 'dependency soup' artifact (Firebase.Core), then yes, it would be difficult to manage the version of that dependency that you get, because you would need to know which version was packed into each version of Firebase.Core. However, for dependencies which I've been able to split out of Firebase.Core (like PromisesObjC, which contains FBLPromises), they are published to NuGet with version numbers that are prefixed by their native library versions, so you can constrain or pick compatible versions as needed.

Further, as far as Google Sign In is concerned, these dependencies have been cleanly separated from Firebase.Core for quite a while now, so you shouldn't have to worry about this at all.

Or maybe I misunderstood this question.

[Kapusch]

Thanks Adam. I'm trying to sort all this out to make it clear and plan the next steps. Also, I noticed this PR #43 may be good source of info.

If you want to, I could share with you my plan here in the next days to confirm whether this makes sense to you or not. I'm really grateful about your support and feedbacks to make things cleaner.

[AdamEssenmacher]

If you're looking to contribute back, definitely post here with your plan and any questions.

The PR you linked is fairly similar to Google Sign In, yes.

[Kapusch]

Hi Adam,

Thanks again for offering to review a contribution plan.

Here's high-level what I am planning to do:

1. Create dedicated Facebook SDK bindings repos by platform:
   • Kapusch.FacebookApisForiOSComponents
   • Kapusch.FacebookApisForAndroidComponents
     Note: I’ve also contacted the Microsoft team maintaining dotnet/android-libraries to ask whether they’d consider supporting/maintaining Facebook Android bindings there; if they’re open to it, I’ll align my Android work accordingly.
2. Upgrade Google Sign-In iOS in your repo from v8 → v9 (your repo already has the v8 binding).
3. Then, on the Plugin.Firebase side, I plan to:
   a. rework/normalize some Auth exception handling (I’m seeing native iOS Auth exceptions),
   b. implement missing Auth APIs like user reload / re-auth flows (e.g. “requires-recent-login” scenarios),
   c. add language selection for Firebase Auth emails,
   d. and implement App Check.

Do you have any repo conventions for upstream contributions (e.g. stacked PRs vs one larger PR)?

Have a nice day, thanks.

[AdamEssenmacher]

• Create dedicated Facebook SDK bindings repos by platform:
• Kapusch.FacebookApisForiOSComponents
• Kapusch.FacebookApisForAndroidComponents

Xamarin/Microsoft used to maintain both. I did some work a while back to bring Core and Share up to current, but haven't kept up with it (and don't use it myself anymore). Feel free to use as a reference or starting point: https://github.com/AdamEssenmacher/FacebookComponents

• I’ve also contacted the Microsoft team maintaining dotnet/android-libraries to ask whether they’d consider supporting/maintaining Facebook Android bindings there; if they’re open to it, I’ll align my Android work accordingly.

They won't. And I try not to remind them that they're still maintaining the Android Firebase bindings 🙃

• Upgrade Google Sign-In iOS in your repo from v8 → v9 (your repo already has the v8 binding).

There are three major parts to this:

1. Updating any dependencies that have shifted over the major version. Sometimes this is as easy as bumping version numbers. Sometimes, it means adding and/or removing dependencies.
2. Updating the binding code. A good starting point for this is diffing the header files between the two versions. Sometimes there aren't any changes. Sometimes it's just a few methods that need to be added/removed. If entirely new types have been introduced, this becomes more challenging. It is OK to leave any new APIs unmapped at first--I only add bindings that I intend to test.
3. Updating resources (i.e., images, language files). This is just tedious and another job for a diff tool.

rework/normalize some Auth exception handling (I’m seeing native iOS Auth exceptions),

I almost did this in my v4 PR, but stopped myself since there were a lot of other changes going on. My approach would have been to remove the Plugin.Firebase middleware exception types entirely (and so always allowing the native exceptions to propagate). I figured this might be an unpopular decision (which is another reason I held off for v4), but I have some good reasons for preferring it. Whichever way we go, the approach should be internally consistent across Plugin.Firebase and, as you've noted, this is not the case.

• implement missing Auth APIs like user reload / re-auth flows (e.g. “requires-recent-login” scenarios),
• add language selection for Firebase Auth emails,

Great!

• and implement App Check.

iOS bindings are needed for this. Microsoft had gotten started on them, but never published them. I finished them for myself at one point (before I took over the bindings entirely), but had to drop AppCheck for the moment because of bugs in AppCheck itself. I just haven't gone back to re-add and publish them for current Firebase.

One question: Any repo conventions you prefer for upstream contributions (stacked PRs vs one larger PR)?

Thanks for asking. I should probably add some more to contributing.md

• PRs will be squash-merged into main.
• main should be 'release-ready' at all points of its history (there's no actual CD though)
• PRs should be small and focused. When in doubt, go smaller.
• PRs should not contain changes unrelated to their stated purpose. This includes fixing warnings, refactoring, reformatting, commenting, documentation, etc.
• I do not care about tabs vs. spaces, but don't break the convention of whatever file(s) you're updating. New files should follow the convention of similar / nearby files. I'm pretty sure this repo has both (it came like that). Normalizing across the solution would be its own PR.

[Kapusch]

Thanks for the recommendations! I wasn't aware they had maintained Facebook too.

I will start working on my plan soon and make sure to consider your feedbacks 👍