Binary XCFramework distribution

[fabio914]

Do you have plans to also distribute releases as XCFrameworks?

It's actually not straightforward to create an XCFramework from a Swift Package, and it's not always feasible.

[fabio914]

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

[petea]

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

[xhp281]

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

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

[erikkerber]

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

[jpike88]

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

[natanrolnik]

Plus one for distributing built xcframeworks

[maksymbazala]

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.

[azilbershtein]

Plus one for distributing built xcframeworks

[mmdumi]

Any updates here ?

[petea]

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.

[mmdumi]

Thank you @petea Converted to that one.

[dhaval12593]

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?

[cassianomonteiro]

+1

[sandhive24]

+1

[wolfcon]

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

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

[erikkerber]

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

[wolfcon]

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

[erikkerber]

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.

[wolfcon]

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

[erikkerber]

That's what we do.

And is why this issue exists.

[wolfcon]

Let official support..🫠

[phongth7]

+1. Same #391 According to recent privacy updates, the Apple Store requires a framework with a signature. We can't utilize CocoaPods or SPM due to constraints in our development environment.

[kevin-c-meister]

We are running into the same issue here with the constraints of the signature on the .xcframework.

[mdmathias]

You can always wrap GSI in your own .xcframework. If you do that, you can sign it yourself. Additionally, it seems that Apple is only going to enforce the signature and privacy manifest requirements for newly added dependencies [1] named in Apple's list of commonly used 3P frameworks [2]. From [1],

Starting May 1, 2024, new or updated apps that have a __newly added__ (emphasis added) third-party SDK that‘s on the list of [commonly used third-party SDKs](https://developer.apple.com/support/third-party-SDK-requirements/) will need all of the following to be submitted in App Store Connect:

  1. Required reasons for each [listed API](https://developer.apple.com/documentation/bundleresources/privacy_manifest_files/describing_use_of_required_reason_api)
  2. [Privacy manifests](https://developer.apple.com/support/third-party-SDK-requirements/)
  3. Valid signatures when the SDK is added as a binary dependency

Looks like if you are using GSI in a previously approved app, then I think the above means the privacy manifest and signature requirements will not be enforced for you.

Regardless, I understand that it's better to be safe; so, please update!

[1] https://developer.apple.com/news/?id=pvszzano [2] https://developer.apple.com/support/third-party-SDK-requirements/