FR: Carthage support

[okydk]

Now that the Firebase SDKs are open source, can we then have Carthage support? 😍

*** Cloning firebase-ios-sdk
*** Checking out firebase-ios-sdk at "4.0.0"
*** Skipped building firebase-ios-sdk due to the error:
Dependency "firebase-ios-sdk" has no shared framework schemes

[morganchen12]

We can't add Carthage support via a shared framework scheme for the time being since all the Firebase libraries have a common dependency in Analytics, which is still closed source and vended as a static library. If we were to try to distribute the other Firebase libs as dynamic frameworks, they would all have link time dependencies on Analytics and would end up duplicating the Analytics classes in the runtime, bloating app size and causing undefined behavior in some instances.

Carthage does support vending binaries, so we could still distribute these as static binaries with static dependencies on Analytics. Others wouldn't be able to easily build and redistribute libraries wrapping Firebase, but otherwise we'd retain many of the benefits of using Carthage. But before this can happen Analytics also needs to be distributed through Carthage, since mixing dependency managers is not something we should encourage developers to do.

The most straightforward solution would be to distribute Analytics as a dynamic framework through Carthage and then build the open source Firebase frameworks on top of that via a shared framework scheme. This is unlikely to happen in the very short term. In the longer term, we'd need to weigh the drawback of causing longer app launch times for dylib users versus the benefit of allowing users to install Firebase through Carthage and easily build frameworks wrapping Firebase. If you have either of these concerns (app launch times/want to build on top of Firebase), please share your thoughts!

[okydk]

Ok, fingers crossed for support in the future 🤞 and thanks for the clarification.

[soheilbm]

For time being I already created a carthage compatible for firebase. https://github.com/soheilbm/firebase

[mhuusko5]

@morganchen12 I'm very much interested in building frameworks on top of Firebase, and I think the more Firebase continues to grow as a defacto database and auth/etc. solution, the more people/companies are going to be wrapping it, at least for internal use (but probably convenience frameworks at some point too).
At the moment though I'm most interested in this Analytics topic. From what I can tell at first pass of the source (at least of FirebaseCore), Analytics being present is desired but not required. Is this actually/will this continue to be, the case?

[salqadri]

Hi @mhuusko5. Google Analytics for Firebase is what enables us to offer an integrated experience across the various other Firebase services we offer. As such we try to make Firebase Analytics included in the default experience since this is will maximize the value to our users. A great example of this is the AdMob integration with Firebase. When used together, we are able to combine metrics from both AdMob and Analytics to answer more sophisticated questions like "On which screens are users being exposed to advertising the most or the least?" However, we know that some advanced users may explicitly only want the AdMob SDK which is why we avoid having hard dependencies. So yes, since this is by design, you can expect that we will continue to only be using weak dependencies for the majority of our inter-product integrations. There are other weak dependencies in the codebase as well, such as between Database and Auth, such that Database works without it, but when Auth is included in an app its functionality is enhanced. Hope that clarifies this.

[mhuusko5]

@salqadri fantastic, thanks for the breakdown, and I love the design strategy. 👍

[morganchen12]

@mhuusko5 for the time being you can create frameworks wrapping Firebase for your own personal use by just embedding them in a target and using CocoaPods' inherit! :search_paths without any issues. Life becomes much harder once you try to distribute the framework afterwards.

[AndrewSB]

Distributing Analytics through Carthage shouldn't be too hard. For example, this is what mapbox does: https://www.mapbox.com/ios-sdk/

Relevant line in a consumer's cartfile would be binary "https://www.mapbox.com/ios-sdk/Mapbox-iOS-SDK.json" ~> 3.5, which just points to a JSON file (https://www.mapbox.com/ios-sdk/Mapbox-iOS-SDK.json ) with version numbers and a URL from where to download the .framework

I understand that it will take some time to work through the bureaucracy that comes with being at Google, so I understand that adding complete Carthage support will potentially be a long-term goal 😄
Take your time, thank you for going (almost completely) open source ❤️

[morganchen12]

@AndrewSB for reference the issue here isn't Carthage, it's that we currently don't ship Analytics as a dynamic framework, which we must (should) before distributing it through Carthage.

[AndrewSB]

Ahh, I see. Still a static framework, I take back what I said then. So I guess we're waiting on that dynamic framework then

[paulb777]

Carthage has recently added some info to its README about integrating static frameworks that could be helpful - https://github.com/Carthage/Carthage#build-static-frameworks-to-speed-up-your-apps-launch-times

[TofPlay]

I create some dynamic frameworks compatible with carthage for my own projects with dependencies between them. It's not really complex. And if you want to create a cross-platform framework compatible with carthage you can follow this tutorial I created: Swift Cross Platform Framework 👍