Any guidance to the repo on how to make contributions for updating?

[Digifais]

Is there any guidance on how this repository actually works in order to make contributions to update some packages?

E.g. should the update.cake script be used or is all the work done manually? Where are URLs such as https://dl.google.com/firebase/ios/analytics/cc4d75392af34c62/GoogleAppMeasurement-10.24.0.tar.gz pulled from, I guess the podspecs but are they manually updated or automatically?

[Digifais]

@AdamEssenmacher @vhugogarcia

[AdamEssenmacher]

To be honest, I'm not even sure what the purpose of update.cake is or whether or not it is still useful or relevant.

My advice to anyone looking to contribute or otherwise build these nugets for themselves would be to read through the commit history to see what steps were needed to update it past where Microsoft left us. All of the changes were made by hand.

Where are URLs such as https://dl.google.com/firebase/ios/analytics/cc4d75392af34c62/GoogleAppMeasurement-10.24.0.tar.gz pulled from, I guess the podspecs

Your guess is correct. Links to binary distributions like this, linker flags, and framework dependencies are all gleaned from the podspecs.

To sniff out dependencies and versions, I run a simple pod install on a podfile like:

# Uncomment the next line to define a global platform for your project
platform :ios, '13.0'

target 'firebase-bindings' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for firebase-bindings
  pod 'FirebaseCore', '10.24.0'
  pod 'FirebaseCoreExtension', '10.24.0'
  pod 'FirebaseCoreInternal', '10.24.0'
  pod 'FirebaseSessions', '10.24.0'
  pod 'FirebaseSharedSwift', '10.24.0'  
  pod 'FirebaseAppCheckInterop', '10.24.0'
  pod 'FirebaseAuthInterop', '10.24.0'
  pod 'FirebaseMessagingInterop', '10.24.0'
  pod 'FirebaseFirestoreInternal', '10.24.0' 
  pod 'FirebaseRemoteConfigInterop', '10.24.0'
  
  pod 'FirebaseABTesting', '10.24.0'
  pod 'FirebaseAnalytics', '10.24.0'
  pod 'FirebaseAuth', '10.24.0'
  pod 'FirebaseCrashlytics', '10.24.0'
  pod 'FirebaseDatabase', '10.24.0'
  pod 'FirebaseDynamicLinks', '10.24.0'
  pod 'FirebaseFirestore', '10.24.0'
  pod 'FirebaseFunctions', '10.24.0'
  pod 'FirebaseInAppMessaging', '10.24.0-beta'
  pod 'FirebaseInstallations', '10.24.0'
  pod 'FirebaseMessaging', '10.24.0'
  pod 'FirebasePerformance', '10.24.0'
  pod 'FirebaseRemoteConfig', '10.24.0'
  pod 'FirebaseStorage', '10.24.0'

  #pod 'Google-Mobile-Ads-SDK', '9.12.0'
  #pod 'GoogleUserMessagingPlatform', '1.1.0'
  #pod 'GoogleSignIn', '7.0.0'
  #pod 'GoogleMaps', '7.3.0'
  #pod 'GooglePlaces', '7.3.0'

  #pod 'MLKitCommon', '11.0.0'
  #pod 'MLKitVision', '7.0.0'
  #pod 'MLImage', '1.0.0-beta5'
  #pod 'MLKitImageLabelingCommon', '7.0.0'
  #pod 'MLKitObjectDetectionCommon', '7.0.0'
  #pod 'GoogleToolboxForMac', '4.2.1'
  #pod 'GoogleUtilitiesComponents', '1.1.0'
  #pod 'SSZipArchive', '2.4.2'
  #pod 'MLKitBarcodeScanning', '5.0.0'
end

If dependencies haven't changed, upgrading can be a relatively simple process of just bumping version numbers in component.cake and changing links in the .targets files.

[AdamEssenmacher]

I'll also say... It would be really nice to have this process automated. My experience with this project is that it hinges on a fair amount of 'tribal knowledge'. It is time-consuming to maintain and extraordinarily difficult to pick up from scratch. I suspect these are the main reasons Microsoft abandoned it, as its original maintainers have moved on and never got this project to a 'good' place where it was easier to maintain. The sister project on the Android side has more of the script automation you'd hope for (and still has its maintainer...), and Microsoft is still supporting it.

So @Digifais if you'd like to have a go at contributing (maybe updating from 10.24 -> 10.25?), feel free to ask specific questions here and I'll offer any assistance I can.

[Digifais]

@AdamEssenmacher I've been trying to update GoogleSignIn first, but just on trying to run the externals task on that library on the current version as left behind, I'm getting:

[!] CocoaPods could not find compatible versions for pod "GTMSessionFetcher/Core":
  In Podfile:
    GTMAppAuth (= 1.2.1) was resolved to 1.2.1, which depends on
      GTMSessionFetcher/Core (~> 1.5)

None of your spec sources contain a spec satisfying the dependency: `GTMSessionFetcher/Core (~> 1.5)`.

You have either:
 * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

So adding PodSpec.Create ("GTMSessionFetcher", "1.5.0", frameworkSource: FrameworkSource.Pods, subSpecs: new [] { "Core"}), to GOOGLE_SIGN_IN_ARTIFACT.PodSpecs fixed this. But then I'm getting:

[!] CocoaPods could not find compatible versions for pod "GTMSessionFetcher/Full":
  In Podfile:
    GTMSessionFetcher/Full (= 3.4.1)

None of your spec sources contain a spec satisfying the dependency: `GTMSessionFetcher/Full (= 3.4.1)`.

You have either:
 * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

How would I tackle this, adding it in the same way as stated above doesn't solve this.

[AdamEssenmacher]

GTMSessionFetcher is a pod. As in, it is a dependency artifact that, in iOS world, would be analogous to a NuGet package in .NET. I'm sure you know this already.

Ideally, pod dependencies like this would be 1:1 for NuGet packages. For example, there really should be something like an AdamE.GTMSesseionFetcher NuGet package that wraps the pod and mirrors its versioning constraints. This is how the Android component library works.

Unfortunately, this is not the approach the original Microsoft team took with the iOS bindings for reasons I can't fathom (except for the obvious... expediency?). Instead, common Google/Firebase dependencies such as GTMSessionFetcher, GoogleAppMeasurement, and PromisesObjC are all part of the Firebase.Core NuGet package. So, despite GoogleSignIn not being a 'Firebase' product, it has a dependency on this sort of monolith dumping ground Firebase.Core, which includes the needed GTMSessionFetcher dependency (along with a bunch of other common Google/Firebase xcframeworks).

I wouldn't expect the build tasks to run correctly in the current state of this repo for GoogleSignIn--it's just not one of the projects I've brought forward from where Microsoft left it.

I posted a podfile above. If your goal is to get GoogleSignIn working, your first step should be to uncomment the #pod 'GoogleSignIn' line (and update it to your target version). If you can run a pod install on that file successfully, the CLI will print out the resolved pod dependencies/versions we need for the next steps.

[Digifais]

@AdamEssenmacher Wouldn't looking at the podspec yield the same result as using the podfile you posted above? I already figured that GoogleSignIn has a dependency on FirebaseCore, but I don't understand why it would throw the error for GTMSessionFetcher since FirebaseCore includes that dependency?

[Digifais]

@AdamEssenmacher Wouldn't looking at the podspec yield the same result as using the podfile you posted above? I already figured that GoogleSignIn has a dependency on FirebaseCore, but I don't understand why it would throw the error for GTMSessionFetcher since FirebaseCore includes that dependency?

Nevermind, it was because of a version mismatch between the GTMSessionFetcher/Core dependency of GoogleSignIn and the GTMSessionFetcher/Full dependency of FirebaseCore.

[AdamEssenmacher]

You would have to look at all the podspecs and calculate the compatible versions of all the pod dependencies yourself... basically doing package resolution. That's what cocoapods is for.

You said your first step was trying to run the externals build for GoogleSignIn as-is. Let's look at why that doesn't work. Looking at components.cake, we see:

	GOOGLE_SIGN_IN_ARTIFACT.PodSpecs = new [] {
		PodSpec.Create ("GoogleSignIn", "5.0.2"),
		PodSpec.Create ("AppAuth",      "1.4.0", frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("GTMAppAuth",   "1.2.1", frameworkSource: FrameworkSource.Pods),
	};

Notice how GTMSessionFetcher isn't in there? That's because it is a common dependency, and therefore included as a reference to FIrebase.Core:

GOOGLE_SIGN_IN_ARTIFACT.Dependencies      = new [] { FIREBASE_CORE_ARTIFACT };

And FIREBASE_CORE_ARTIFACT is further configured:

	FIREBASE_CORE_ARTIFACT.PodSpecs = new [] {
	    PodSpec.Create ("FirebaseAppCheckInterop",     "10.24.0",    frameworkSource: FrameworkSource.Pods),
	    PodSpec.Create ("FirebaseAuthInterop",         "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseCore",                "10.24.0",    frameworkSource: FrameworkSource.Pods),		
		PodSpec.Create ("FirebaseCoreExtension",       "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseCoreInternal",        "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseMessagingInterop",    "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseRemoteConfigInterop", "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseSessions",            "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("FirebaseSharedSwift",         "10.24.0",    frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("GTMSessionFetcher",           "3.4.1",      frameworkSource: FrameworkSource.Pods, subSpecs: new [] { "Full" }),
		PodSpec.Create ("GoogleAppMeasurement",        "10.24.0"),
		PodSpec.Create ("GoogleDataTransport",         "9.4.1",      frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("PromisesObjC",                "2.4.0",      frameworkSource: FrameworkSource.Pods, frameworkName: "FBLPromises", targetName: "PromisesObjC"),
		PodSpec.Create ("PromisesSwift",               "2.4.0",      frameworkSource: FrameworkSource.Pods, frameworkName: "Promises", targetName: "PromisesSwift"),
		PodSpec.Create ("GoogleUtilities",             "7.13.3",     frameworkSource: FrameworkSource.Pods, subSpecs: new [] { "AppDelegateSwizzler", "Environment", "Logger", "ISASwizzler", "MethodSwizzler", "Network", "NSData+zlib", "Privacy", "Reachability", "UserDefaults", }),
		PodSpec.Create ("nanopb",                      "2.30910.0",  frameworkSource: FrameworkSource.Pods),
		PodSpec.Create ("leveldb-library",             "1.22.5",     frameworkSource: FrameworkSource.Pods, frameworkName: "leveldb"),
	};

It's important to realize that the cake build uses components.cake to build a podfile. So, as configured, that podfile would end up looking something like:

platform :ios, '13.0'

target 'firebase-bindings' do
  use_frameworks!

  pod 'GoogleSignIn', '5.0.2'
  pod 'AppAuth', '1.4.0'
  pod 'GTMAppAuth', '1.2.0'
  pod 'FirebaseCore', '10.24.0'
  pod 'FirebaseCoreExtension', '10.24.0'
  pod 'FirebaseCoreInternal', '10.24.0'
  pod 'FirebaseSessions', '10.24.0'
  pod 'FirebaseSharedSwift', '10.24.0'  
  pod 'FirebaseAppCheckInterop', '10.24.0'
  pod 'FirebaseAuthInterop', '10.24.0'
  pod 'FirebaseMessagingInterop', '10.24.0'
  pod 'FirebaseFirestoreInternal', '10.24.0' 
  pod 'FirebaseRemoteConfigInterop', '10.24.0'
  pod 'GTMSessionFetcher', '3.4.1'
  pod 'GoogleAppMeasurement', '10.24.0'
  pod 'GoogleDataTransport', '9.4.1'
  pod 'PromisesObjC', '2.4.0'
  pod 'PromisesSwift', '2.4.0'
  pod 'nanopb', '2.30910.0'
  pod 'leveldb-library', '1.22.5'
end

If you were to try running a pod install on this file, it would fail for the very same reason you've seen:

[!] CocoaPods could not find compatible versions for pod "GTMAppAuth":
  In Podfile:
    GTMAppAuth (= 1.2.0)

None of your spec sources contain a spec satisfying the dependency: `GTMAppAuth (= 1.2.0)`.

You have either:
 * out-of-date source repos which you can update with `pod repo update` or with `pod install --repo-update`.
 * mistyped the name or version.
 * not added the source repo that hosts the Podspec to your Podfile.

To understand why CocoaPod can't find a 'compatible version', consider this high-level podfile:

# Uncomment the next line to define a global platform for your project
platform :ios, '13.0'

target 'firebase-bindings' do
  # Comment the next line if you don't want to use dynamic frameworks
  use_frameworks!

  # Pods for firebase-bindings
  pod 'FirebaseCore', '10.24.0'
  pod 'FirebaseCoreExtension', '10.24.0'
  pod 'FirebaseCoreInternal', '10.24.0'
  pod 'FirebaseSessions', '10.24.0'
  pod 'FirebaseSharedSwift', '10.24.0'  
  pod 'FirebaseAppCheckInterop', '10.24.0'
  pod 'FirebaseAuthInterop', '10.24.0'
  pod 'FirebaseMessagingInterop', '10.24.0'
  pod 'FirebaseFirestoreInternal', '10.24.0' 
  pod 'FirebaseRemoteConfigInterop', '10.24.0'
  
  pod 'FirebaseABTesting', '10.24.0'
  pod 'FirebaseAnalytics', '10.24.0'
  pod 'FirebaseAuth', '10.24.0'
  pod 'FirebaseCrashlytics', '10.24.0'
  pod 'FirebaseDatabase', '10.24.0'
  pod 'FirebaseDynamicLinks', '10.24.0'
  pod 'FirebaseFirestore', '10.24.0'
  pod 'FirebaseFunctions', '10.24.0'
  pod 'FirebaseInAppMessaging', '10.24.0-beta'
  pod 'FirebaseInstallations', '10.24.0'
  pod 'FirebaseMessaging', '10.24.0'
  pod 'FirebasePerformance', '10.24.0'
  pod 'FirebaseRemoteConfig', '10.24.0'
  pod 'FirebaseStorage', '10.24.0'

  pod 'GoogleSignIn', '5.0.2'

end

The purpose of this podfile is to have CocoaPods resolve dependencies (if possible) that would be compatible with GoogleSignIn 5.0.2 and all of the other artifacts. Trying to run pod install on this results in an error:

CocoaPods could not find compatible versions for pod "GTMSessionFetcher/Core":
  In Podfile:
    FirebaseAuth (= 10.24.0) was resolved to 10.24.0, which depends on
      GTMSessionFetcher/Core (< 4.0, >= 2.1)

    GoogleSignIn (= 5.0.2) was resolved to 5.0.2, which depends on
      GTMAppAuth (~> 1.0) was resolved to 1.3.1, which depends on
        GTMSessionFetcher/Core (< 3.0, >= 1.5)

    GoogleSignIn (= 5.0.2) was resolved to 5.0.2, which depends on
      GTMSessionFetcher/Core (~> 1.1)

CocoaPods is telling us that, for the versions we've configured (i.e. Firebase 10.24 and GoogleSignIn 5.0.2), there is no compatible artifact for the GTMSessionFetcher that satisfy both. Put simply: FirebaseAuth 10.24 is not compatible with GoogleSignIn 5.0.2.

So, returning to your original goal:

just on trying to run the externals task on that library on the current version as left behind

"As left behind" (as in, where Microsoft left it), the GoogleSignIn NuGet package was built to be compatible with Firebase 8.10, which was compatible with GoogleSignIn 5.0.2. To bring the GoogleSignIn artifact out of the past and into a state where it would once again be compatible with AdamE.Firebase.Core, GoogleSignIn will need to be bumped to the minimum version that is compatible with FirebaseAuth 10.24, which is 6.2.4.

The major version bump most likely means there will be some breaking API changes, which means we need to research and adjust GoogleSignIn's ApiDefinition.cs and/or Enums.cs as needed. Errors resulting from this step might manifest themselves during the libs build, but sometimes not until runtime.

Version 6.0.0 release notes

[Digifais]

@AdamEssenmacher Looking at the podspec for GoogleSignIn 5.0.2 and the latest version 8.0.0 (but this has been since the next version after 5.0.2, being 6.0.0), the source URL has changed from a download link to the GitHub repo.

Changing it in the targets file of GoogleSign to this works, but the contents of what is inside has changed (e.g. no framework anymore but just the plain source code):

    <XamarinBuildDownload Include="$(_GoogleSignInItemsFolder)">
      <Url>https://github.com/google/GoogleSignIn-iOS/archive/refs/tags/8.0.0.tar.gz</Url>
      <Kind>Tgz</Kind>
    </XamarinBuildDownload>

Any ideas on how to go about this now?

[AdamEssenmacher]

A key property in the podspec is source. In the 5.0.2 podspec, it looks like

  "source": {
    "http": "https://dl.google.com/dl/cpdc/4d5ad0c02cd38abf/GoogleSignIn-5.0.2.tar.gz"
  },

When dealing with Google's pods, seeing a tarball source is a solid indicator that the source is precompiled code (i.e. a framework). If you download the file and extract it, you can verify that this is the case. Google Pods are usually distributed this way when the source code is private. In this GoogleApisForiOSComponents project, precompiled frameworks like this are downloaded during NuGet package restore using XamarinBuildDownload, which is why we have the XamarinBuildDownload item in the .targets file.

Now, in the 8.0.0 podspec, source looks like

  "source": {
    "git": "https://github.com/google/GoogleSignIn-iOS.git",
    "tag": "8.0.0"
  },

This means that the source is no longer being distributed as a pre-compiled binary, but as a git tag. On one hand, this is a good thing. The XamarinBuildDownload tool is hacky and temperamental. On the other hand, it means that there's a lot more work to do to accomplish the task at hand. Because the source has changed fundamentally, updating the .targets file is not a relatively simple exercise of bumping version numbers and links--whole parts of it will need to be rewritten instead.

There are plenty of examples of csproj/targets combos that do not use XamarinBuildDownload (such as CloudFirestore) in the Firebase directory. These should be used as examples demonstrating how to consume pods with git sources.

There is one other major area of concern here: How does the shift from tarball to git sources impact Resources?

The GoogleSignIn pod ships with UI Resources (e.g. images, resource strings). When it was distributed as a binary, all of those resources were included in a .bundle file included in the tarball along with the compiled framework. In the SignIn.targets file, each of these resources is included and mapped explicitly. For example:

<BundleResource Include="$(_GoogleSignInSDKBaseFolder)Resources\GoogleSignIn.bundle\Info.plist" Visible="False">
  <LogicalName>GoogleSignIn.bundle\Info.plist</LogicalName>
</BundleResource>

_GoogleSignInSDKBaseFolder is the directory that XamarinBuildDownload extracted the tarball to. If we remove XamarinBuildDownload, these resource files will need to be retrieved from elsewhere (they're included in the pod).

In summary, I think the path forward looks like:

1. Replace the ItemGroup/NativeReference item in SignIn.targets with a new ItemGroup to directly include the new xcframework. AppAuth and GTMAppAuth are examples within SignIn.targets that can be followed to accomplish this.
2. Move all of the BundleResource includes out of SignIn.targets and into SignIn.csproj where you can reference the externals directory. As a quick note, the .targets file is ultimately packed in the nuget and used by package consumers--so you should not reference anything on your local file system in there! One last thought about these resources; you should be careful not to assume that these resources are 1:1 from versions 5 -> 8. Some may have been added or removed.

[Digifais]

Is step 2 regarding the BundleResources still necessary to do if they are already included in the .bundle folder when exploring the built NuGet package after doing step 1?

[AdamEssenmacher]

I think so? AFAIK, Xamarin/MAUI build tooling doesn't auto-include resource bundles it finds in NuGet packages. I haven't looked into this closely though, so take that as a heavily-qualified AFAIK

[Digifais]

@AdamEssenmacher Thanks once again for your extensive response to my question, I'll look into this tomorrow as I was just about to go to bed.

In the meantime, I've been running into the following issue: #35 on Mac (so not the long path issue) and can't seem to get this working, even when trying the suggested solution. Do you have any ideas for that?

Edit: for some reason, it also keeps downloading GoogleAppMeasurement-8.9.1 instead of GoogleAppMeasurement-10.24.0 inside GAppM-10.24.0, no idea why that is either since <_GoogleAppMeasurementSDKBaseFolder>$(XamarinBuildDownloadDir)$(_GoogleAppMeasurementItemsFolder)\GoogleAppMeasurement-10.24.0\Frameworks\</_GoogleAppMeasurementSDKBaseFolder> is correctly set in Core.targets.

[AdamEssenmacher]

I think we need to tap the brakes a bit.

Updating GoogleSIgnIn is far from 'done'. There is no PR, no code review, and it has not been released for community validation.

Updating Firebase packages should be done incrementally to help isolate any breaking changes (should they occur).

How is #38 'faulty'? That should be described in an issue and fixed in isolation.

I'm not going to pull in a monolithic PR with a ton of unrelated changes mixed in.

[Digifais]

@AdamEssenmacher No problem. What I meant with "consider GoogleSignIn done", is that I think I've done sufficient work with updating it and testing it locally here in that it's ready to create a PR to merge to the repo. I'll get around breaking things up in smaller parts and creating PR's in due time.

I did most of this on company time as we have some strict deadlines for the end of the year for our app (one of these was implementing Google Consent Mode v2, hence what brought me to updating the Firebase Analytics binding as I needed the change mentioned here), we also have our private NuGet feed, so I'm unblocked as far as this goes.

I did drop Xamarin.iOS support though in the updated bindings locally, as well as updated from .NET 6 to .NET 8, I'm not sure how keen you are on that?

[AdamEssenmacher]

It’s great to hear that this project has been valuable for your company. I hope your employer sees the benefit of allowing you the time to contribute back—or even consider sponsoring the project! 😊

A couple of things to keep in mind... First, contributing PRs back means your updates can benefit from my review as the project maintainer. Second, I’m confident we could get a public NuGet published very quickly. Depending on your release cycle, you might see other developers using the new package in production weeks or even months before you, which could help reduce risk on your release day.

I’ve fixed some issues in the project today, so be sure to check out the latest on the main branch. Additionally, I’m planning to release incremental updates to Firebase over the next few days, aiming to reach version 10.29—so keep an eye out for those!

Regarding dropping Xamarin.iOS support, my plan is to continue releasing updates in a Xamarin-compatible way for iOS AdamE.* binding packages until Apple stops accepting Xcode 15 builds (likely around April 2025). That said, having a branch prepared for a .NET 7 (or even 8) conversion ahead of time would be really helpful when the transition becomes necessary.

As a quick note, when creating PRs, it’s super helpful if they focus on the specific changes or fixes being addressed. Avoiding unrelated whitespace or formatting adjustments makes it much easier to review and ensures that we can get your contributions merged faster.

Thank you for all the effort you've already put into this, and for considering contributing back to the project. Your work and insights are really appreciated.

[Digifais]

While I do get that you want to release incremental updates for the Firebase libraries, is there no way we can aim to go directly for the latest version, 11.3.0? If so, I would be more than happy to contribute to this as well, as that is what I've done for the needed Firebase libraries in our app at this moment. But I'm not quite sure if I can manage to make more time free soon and take two steps back to help you update to 10.29.

[AdamEssenmacher]

I won't need help updating to 10.29. It'd be nice to have any changes that were necessary to the API surface (ApiDefnintions, Enums) for the major version increase though. And maybe we can compare notes on the dependency upgrades

[Digifais]

@AdamEssenmacher Upon updating the ApiDefinitions for GoogleSignIn v8.0.0, there is a new property introduced being:

// @property (readonly, nonatomic) id<GTMFetcherAuthorizationProtocol> _Nonnull fetcherAuthorizer;
[Export("fetcherAuthorizer")]
GTMFetcherAuthorizationProtocol FetcherAuthorizer { get; }

This is currently throwing the last build error I have left stating that the type is missing. This particular type is originating from GTMSessionFetcher. How would I go about to fix this build error?

[AdamEssenmacher]

It sounds like a binding needs to be written for the GTMFetcherAuthorizationProtocol type! I can imagine a handful of ways to solve for this:

1. Leave this property commented out for now with a TODO
2. Add the binding for GTMFetcherAuthorizationProtocol to the ApiDefinition.cs file for GoogleSignIn
3. Add the binding for GTMFetcherAuthorizationProtocol to the ApiDefinition.cs file for Firebase.Core
4. Split GTMSessionFetcher out into its own AdamE.* artifact, with its own binding project and ApiDefinition.cs binding definition.

As these things often go, these options are ordered in increasing levels of both correctness and difficulty. (1) should get you building at least, but it looks like this property is going to be crucial for much of the libraries core functionality. (2) should work just fine, but would introduce some new tech debt that would need to be addressed if/when another library in this project needs to reference the type. (3) wouldn't introduce any new problems. (4) would be the cleanest. I vote (3).

By the way, it is standard convention when writing these bindings to remove the ObjectiveC-style type prefixes for the C# types. For example, FIRApp -> App, GIDGoogleUser -> GoogleUser, GTMFetcherAuthorizationProtocol -> FetcherAuthorizationProtocol

[Digifais]

3. Add the binding for GTMFetcherAuthorizationProtocol to the ApiDefinition.cs file for Firebase.Core

I think I just finished up the binding for GTMFetcherAuthorizationProtocol, or actually the whole GTMSessionFetcher library since it went quite extensive, inside a new ApiDefinition_GTMSessionFetcher.cs file inside the Firebase.Core project locally for my own 11.3 NuGets for the app of the company I currently work for. That way I was able to uncomment the property inside GoogleSignIn v8.0.0 ApiDefinition right now.

[AdamEssenmacher]

or actually the whole GTMSessionFetcher library

This might have been overkill. I think we only needed the one type bound?

[Digifais]

This is a typo right:

GoogleApisForiOSComponents/source/Firebase/Core/Core.targets

Line 182 in 4a02b5b

<_NativeReference Update="@(_NativeReference)" Condition="'%(_NativeReference._Id)' == '$(_ProimisesId)'">

Proimises vs Promises? Fixing the typo gives the following build errors though:

 ../../../externals/Promises.xcframework : error : Unknown native reference type for ''. [/GoogleApisForiOSComponents/source/Firebase/Core/Core.csproj]
                   ../../../externals/Promises.xcframework : error :          [/GoogleApisForiOSComponents/source/Firebase/Core/Core.csproj]
                     ../../../externals/FirebaseSessions.xcframework : error : Unknown native reference type for ''. [/GoogleApisForiOSComponents/source/Firebase/Core/Core.csproj]
                   ../../../externals/FirebaseSessions.xcframework : error :          [/GoogleApisForiOSComponents/source/Firebase/Core/Core.csproj]

[AdamEssenmacher]

Yes, that does look like a typo.

[AdamEssenmacher]

Taking a closer look, this typo was compounded by another typo 😮‍💨

Thanks for the callout.

[Digifais]

Just a notice, as we are using the Maps SDK for iOS in our app as well, this will be another one I will be tackling right now to bring it up to date to the latest version, being 9.1.1 at the time of writing this comment. There is no dependency on Firebase libraries with this one, so I would imagine this would be an interesting one to pull in this repo, although it's not updated incremental. There seems to be some community members also interested in this looking at #31.

[Digifais]

It's mostly the ArgumentSemantic enum in the Export attribute that differs though, not really the attributes itself. I'll attach what sharpie gives me. The following is my command with the path redacted a bit:
sharpie bind --sdk=iphoneos18.0 --output="XamarinApiDef2" --namespace="Google.Maps" --scope="/xxx/GoogleMaps-9.1.1/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64/GoogleMaps.framework/Headers" "/xxx/GoogleMaps-9.1.1/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64/GoogleMaps.framework/Headers/GoogleMaps.h" -c -F /xxx/GoogleMaps-9.1.1/Maps/Frameworks/GoogleMaps.xcframework/ios-arm64 -framework GoogleMaps -F /xxx/GoogleMaps-9.1.1/Base/Frameworks/GoogleMapsBase.xcframework/ios-arm64 -framework GoogleMapsBase

XamarinApiDef2.zip

[Digifais]

@AdamEssenmacher I think I'm finished and can whip up a PR for GoogleMaps v9.1.1:

[AdamEssenmacher]

That's great @Digifais I look forward to seeing it! Sorry I didn't respond earlier but I was out yesterday. It sounds like you found some well-qualified help too!

[Digifais]

No problem at all @AdamEssenmacher, I created the PR yesterday (#43).

[AdamEssenmacher]

I made a PR back to your fork as an initial cleanup pass so we can focus on the relevant code changes.

[Digifais]

I think I'm nearly there with updating the ApiDefinitions, Enums, Structs and Extensions for Google Maps v9.1.1, however there is one build error left.

I'm getting: Error CS0308: The non-generic type 'FeatureLayer' cannot be used with type arguments (CS0308) on the following:

// -(GMSFeatureLayer<GMSPlaceFeature *> * _Nonnull)featureLayerOfFeatureType:(GMSFeatureType _Nonnull)featureType __attribute__((swift_name("featureLayer(of:)")));
        [Export("featureLayerOfFeatureType:")]
        FeatureLayer<PlaceFeature> FeatureLayerOf(string featureType);

FeatureLayer is defined as such:

    // audit-objc-generics: @interface GMSFeatureLayer<__covariant T : id<GMSFeature>> : NSObject
    [BaseType(typeof(NSObject), Name = "GMSFeatureLayer")]
    [DisableDefaultCtor]
    interface FeatureLayer
    {
        // @property (readonly, nonatomic) GMSFeatureType _Nonnull featureType;
        [Export("featureType")]
        string FeatureType { get; }

        // @property (readonly, getter = isAvailable, nonatomic) BOOL available;
        [Export("available")]
        bool Available { [Bind("isAvailable")] get; }

        // @property (nonatomic) GMSFeatureStyle * _Nullable (^ _Nullable)(T _Nonnull) style;
        [NullAllowed, Export("style", ArgumentSemantic.Assign)]
        Func<Feature, FeatureStyle> Style { get; set; }

        // -(instancetype _Nonnull)initWithFeatureType:(GMSFeatureType _Nonnull)featureType;
        [Export("initWithFeatureType:")]
        NativeHandle Constructor(string featureType);
    }

And Feature is defined as such:

    interface IFeature
    {

    }

#if NET
    [Model]
#else
    [Model(AutoGeneratedName = true)]
#endif
    [Protocol]
    [BaseType(typeof(NSObject), Name = "GMSFeature")]
    interface Feature
    {
        // @required -(GMSFeatureType _Nonnull)featureType;
        [Abstract]
        [Export("featureType")]
        string FeatureType { get; }
    }

Is this just a case of removing the generic type argument in the binding and managing the type at runtime to avoid the compile-time error in C#? Or do you have any other solution how I should go about this?

[Digifais]

According to Rolf in the .NET Discord, the way to go was making the return type ofFeatureLayer<PlaceFeature> FeatureLayerOf(string featureType); non-generic. You might have to type cast though when trying to consume this method.

So: FeatureLayer FeatureLayerOf(string featureType);