Binary XCFramework distribution about googlesignin-ios HOT 21 OPEN

No immediate plans, but open to this if there's sufficient demand.

from googlesignin-ios.

This is causing major issues for our workflow, we use firebase and are struggling to get Xcode to building for simulator on M1 macs. Can this pls be a priority

from googlesignin-ios.

Plus one for distributing built xcframeworks

from googlesignin-ios.

I actually just updated the project that I was using to download GoogleSignIn with Carthage to use XCFrameworks.

from googlesignin-ios.

没有立即的计划，但如果有足够的需求，就会对此持开放态度。

can you do like this? https://github.com/firebase/firebase-ios-sdk/releases/tag/8.8.0

from googlesignin-ios.

@petea A vote here 👋🏼

A distributed XCFramework makes building on Apple Silicon possible (well, easier) for us. We build with Bazel and Cocoapods/SPM aren't tools we utilize.

We can build ourselves as an alternative, but there is a modern utility to XCFrameworks now that all Mac Pros are Apple Silicon. If that's a big step, even including an arm64-simulator slice in the release would help.

from googlesignin-ios.

any updates here? I have an old custom build system on my project and I can use only frameworks/xcframeworks to add new functionality. Any info about when we can get it? Or maybe any advices regarding to how I can make it myself? Thanks.

from googlesignin-ios.

Plus one for distributing built xcframeworks

from googlesignin-ios.

Any updates here ?

from googlesignin-ios.

I expect that we will add an XCFramework distribution to our release process, but I don't have a timeline.

Note that Firebase does release a GoogleSignIn XCFramework as part of their larger binary zip distribution, this may be helpful as a stopgap measure.

from googlesignin-ios.

Thank you @petea
Converted to that one.

from googlesignin-ios.

This helps, thanks.

I am distributing a bunch of dependencies through a SPM and binaryTargets.

While including GoogleSignIn xcframework should I also include the Resources folder?

Looking at https://github.com/google/GoogleSignIn-iOS/blob/main/Package.swift#L74 it looks like the absolute path to this will be GoogleSignIn/Sources/Resources

Where and how should I place the Resources folder exposed in Firebase's release of GoogleSignIn in my SPM package?

from googlesignin-ios.

+1

from googlesignin-ios.

+1

from googlesignin-ios.

Just use Firebase Carthage manual. Those guys are the real deal.
Add carfile

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseGoogleSignInBinary.json"

from googlesignin-ios.

@wolfcon Those are versioned according to Firebase which are difficult (impossible?) to map to GoogleSignin versions.

from googlesignin-ios.

@wolfcon Those are versioned according to Firebase which are difficult (impossible?) to map to GoogleSignin versions.

That's a messy problem. But you can find GoogleSignIn version in info.plist(Framework file). As I know it is only way to map it..

That list covers most of Google service SDK which is always updated with every separated team. Better than manual import.

I have noticed one thing: (Quote)

Versioning

All Firebase components share the same version. Mixing and matching components with different versions may cause linker errors.

If you use multiple google service, the best way to integrate them is through Firebase version. They test it after all.

from googlesignin-ios.

Yeah we use GoogleSignIn alone (powers part of your Slack sign in!)

Being able to target specific versions of GSI without reverse engineering what Firebase version it belongs to is a must.

from googlesignin-ios.

Last way to achieve that goal is maintaining a self-managed GoogleSignIn which is updated by yourself manually, rather than Firebase. 😆

from googlesignin-ios.

That's what we do.

And is why this issue exists.

from googlesignin-ios.

Let official support..🫠

from googlesignin-ios.