Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
jesusmateos1234 opened this issue Feb 21, 2021 · 15 comments · Fixed by #8087
Closed

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

jesusmateos1234 opened this issue Feb 21, 2021 · 15 comments · Fixed by #8087

Comments

@jesusmateos1234
Copy link

Feature proposal

  • Add in assets, xcframeworks in zip files

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

@ryanwilson
Copy link
Member

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.

7.6 release page with Firebase.zip artifact highlighted

@jesusmateos1234
Copy link
Author

jesusmateos1234 commented Mar 1, 2021

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

image

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
Copy link
Member

paulb777 commented Mar 1, 2021

@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

@jesusmateos1234
Copy link
Author

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

@paulb777
Copy link
Member

paulb777 commented Mar 2, 2021

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

@savage7
Copy link

savage7 commented Mar 8, 2021

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
Copy link
Member

paulb777 commented Mar 8, 2021

@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
Copy link

savage7 commented Mar 8, 2021

@paulb777 thank you for your support 😊
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
Copy link
Member

paulb777 commented Mar 8, 2021

@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
Copy link

savage7 commented Mar 8, 2021

@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
Copy link

aehlke commented Apr 15, 2021

@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
Copy link

icedice commented May 18, 2021

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
Copy link
Member

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

@icedice
Copy link

icedice commented May 19, 2021

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
Copy link
Member

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

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants