FR: Add xcframeworks in zip file on tagged assets list for version

[jesusmateos1234]

Feature proposal

• Add in assets, xcframeworks in zip files

For example in tag v7.6.0 add FirebaseCore.xcframework.zip, FirebaseMessagging.xcframework.zip ...

[ryanwilson]

Hi @jesusmateos1234, thanks for the request!

We do have the Firebase.zip download which contains all the XCFrameworks and their associated resources - does this not meet your needs? I don't suspect we'll ever put each XCFramework there individually because it'd be impossible to tell which frameworks you need without reading the README embedded in the zip file.

[jesusmateos1234]

Thanks for your support @ryanwilson. We need to use some xcframeworks (not all) with manual - in house solution- integration. This not mean that Firebase.zip is a good solution for someone who has a bit knowledge or nothing to integrate xcframeworks in his project.

We only need a few of them, we don't required download 300mb of frameworks that we don't use. We need something like Appboy that specify zip files for their xcframeworks. It's a performance question

Including frameworks on project that we not use (or downloading it) will cause the IPA much bigger or spend time that we don't need to spend. We know what frameworks we need to use in base of firebase service that we are using and we will use, and the Github Readme.

It's only add a split of this zip file (but also keeping the largest zip file for other users)

Other solution is provide a urls where we can download these xcframeworks individually if you don't like to put on assets tag version, how you have actually with Carthage (but in this case with xcframeworks not fat binaries)

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAdMobBinary.json"
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"
ETC

* https://dl.google.com/dl/firebase/ios/v7.0.6/FirebaseABTesting.xcframework.zip"
* https://dl.google.com/dl/firebase/ios/v7.0.6//FirebaseAdMobBinary.xcframework.zip"
* https://dl.google.com/dl/firebase/ios/v7.0.6//FirebaseAnalyticsBinary.xcframework.zip"
ETC

This is something critical for us, time to download this zip will cause more time to spend for release a new version.

Thanks for all, i'll hope that this request will be supported.

[paulb777]

@jesusmateos1234 Thanks for the explanation. The Carthage solution might be feasible for us once Carthage adds support for prebuilt binary xcframeworks - which looks to be making progress now at https://github.com/Carthage/Carthage/pull/3123

[jesusmateos1234]

@paulb777 Thanks for your support. Nowadays we not use Carthage, so for this we're requesting this.

[paulb777]

The idea is that if we migrate to xcframeworks for the Carthage distribution, you could use the Carthage URLs.

[savage7]

Since xcframeworks make binary distribution so much easier: Wouldn't it make sense to distriubute as vendored_binary with cocoapdos too?

Firebase is a massive dependency slowing down the simplest iOS project build. We stopped integrating it via cocoapods. We simply added the xcframeworks to the project. However this makes updates a mess...

[paulb777]

@savage7 Distributing as a vendored_binary makes supporting multiple Xcode versions more complicated, makes debugging harder, makes supporting a dynamic or static linking choice impossible, and is less stable in CocoaPods.

Despite that, there is a solution for the slowest part of the Firebase build - Firestore - at https://github.com/invertase/firestore-ios-sdk-frameworks

We also support building your own binaries with the tooling at https://github.com/firebase/firebase-ios-sdk/tree/master/ReleaseTooling

[savage7]

@paulb777 thank you for your support :blush: I understand your concerns regarding "marking it harder" and reducing some options (static/dynamic linking...).

It would be really great if the released frameworks would be available separately on each release, like @jesusmateos1234 proposed. This would make it "easy" to create unofficial/official "binary" podspecs referencing these.

[paulb777]

@savage7 Thanks for the request. We'll investigate options. Would you explain the issue in a bit more detail. I understand the slowness case, but from my understanding, that is almost exclusively a Firestore issue. Where else do you see that with Firebase?

[savage7]

@paulb777 We don't use Firestone, only Messaging and Analytics. The Firebase builds are not slower than other builds, but are simply relatively big dependencies, since both have a large number of sub dependencies. So it's no general problem with Firebase, but with source code dependencies...

The problem arises mostly for our SwiftUI projects, we are forced to reduce our dependencies to an absolute minimum otherwise the SwiftUI Previews are getting unusable (timeouts since the preview gets slow or rebuilds take ages). I've already split up the UI part and the business logic part of our apps into separate frameworks, so the UI only has a minimum set of dependencies.

We are also successfully using https://github.com/grab/cocoapods-binary-cache to prebuild the libs for our devs. But having binary pods from the start would ease the process of speeding up builds alot, since plugins like "cocoapods-binary-cache" have a tendency to break easily...

[aehlke]

@jesusmateos1234 Thanks for the explanation. The Carthage solution might be feasible for us once Carthage adds support for prebuilt binary xcframeworks - which looks to be making progress now at Carthage/Carthage#3123

This is now merged  ✅ (Release pending)

[icedice]

Building with Carthage 0.38 with the --use-xcframeworks flag and adding all the xcframeworks that was build under frameworks in XC and setting to "do not embed" XC fails to build with errors like

Undefined symbol: grpc::ByteBuffer::Dump(std::__1::vector<grpc::Slice, std::__1::allocator<grpc::Slice> >*) const

My cartfile looks like this:

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseABTestingBinary.json"    ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAnalyticsBinary.json"    ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseAuthBinary.json"         ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseCrashlyticsBinary.json"  ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json"    ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseMessagingBinary.json"    ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebasePerformanceBinary.json"  ~> 8.0
binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseRemoteConfigBinary.json" ~> 8.0

I looks like I'm missing some GRPC stuff. The only thing Carthage spit out was gRPC-Core.xcframework which I did include.

What am I doing wrong here?

[paulb777]

The Firestore folder should also include gRPC-C++.xcframework. Did you include that (and everything else from the Firestore zip)?

[icedice]

Manually looking in the Firestore.zip reveals gRPC-C++.xcframework among other stuff, however with a Cartfile like this:

binary "https://dl.google.com/dl/firebase/ios/carthage/FirebaseFirestoreBinary.json" == 8.0

After running the command carthage update --use-xcframeworks

The Carthage/Build folder looks like this:

BoringSSL-GRPC.xcframework
FirebaseFirestore.xcframework
abseil.xcframework
gRPC-Core.xcframework
leveldb-library.xcframework

Seems to me like everything besides gRPC-C++.xcframework is there.

I'm really not sure what's going on here..

[paulb777]

Thanks for the report. I reproduced and opened #8112 to track. Let's continue the discussion there.