Can't build Firebase via PodToBUILD/Bazel

[sgammon]

Step 0: Are you in the right place?

• For issues or feature requests related to the code in this repository
  file a Github issue.
  • If this is a feature request please use the Feature Request template.
• For general technical questions, post a question on StackOverflow
  with the firebase tag.
• For general (non-iOS) Firebase discussion, use the firebase-talk
  google group.
• For backend issues, console issues, and other non-SDK help that does not fall under one
  of the above categories, reach out to
  Firebase Support.
• Once you've read this section and determined that your issue is appropriate for
  this repository, please delete this section.

[REQUIRED] Step 1: Describe your environment

• Xcode version: 11.6
• Firebase SDK version: 6.28.2
• Firebase Component: N/A (Auth, Core, Database, Firestore, Messaging, Storage, etc)
• Component version: N/A
• Installation method: CocoaPods

[REQUIRED] Step 2: Describe the problem

Steps to reproduce:

I am trying to build an iOS app with Firebase included, using PodToBUILD and Bazel. However, there doesn't seem to be an easy integration path, and mapping in pods according to PodToBUILD's docs cause a ton of issues.

Is there a sample project floating around somewhere, or a better integration path with Bazel that doesn't require CocoaPods? Could such an example be published, considering Bazel and Firebase are both part of Google's wider development efforts? :)

Relevant Code:

N/A

[google-oss-bot]

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.

[paulb777]

Some parts of Firebase build internally with Bazel but it hasn't been a priority to fully support for the iOS SDK since there has been substantially less demand than CocoaPods, Carthage, zip distributions and Swift Package Manager.

I've heard of podspec to Bazel translators, but don't know how well they'd do with Firebase.

I'll leave this open for now for additional conversation and thumbs-up votes.

[sgammon]

@paulb777 thank you for responding. yes, i understand your point here, but it's worth noting that Bazel being unusable with Firebase is probably contributing to the lack of demand to use Bazel with iOS writ large, and Firebase merely by consequence. most B2C apps ship with Google libraries of one sort or another, usually from Firebase.

Bazel is a Google technology. it is supposedly a supported development path for iOS. i assume substantive/significant Google B2C iOS apps are written using Bazel, considering J2ObjC and all the other tools created in that universe which are usable from Bazel related to that kind of development.

Firebase is supposedly the blessed SDK/library path for iOS from Google. This is at odds with the statement above this paragraph if the two don't work together.

Say you are a user adopting the Google universe of tools. You have an iOS application, a server-side application to power the iOS application, and so on. If you were to pick Bazel as your build tool (which is sensible, seeing as you may want to harmonize your tooling with your library dependencies), you can no longer participate in the supported SDK path with code provided exclusively by Google (i.e. there is no way to fix this outside of Google).

This makes tool selection w.r.t. Bazel especially murky and confusing. If these things work inside Google with Bazel first, why are they not released that way first? If Bazel is a supported path for iOS, why can't it be used with the "blessed" path of using Firebase SDKs on iOS?

From a user's perspective, I admit it is quite confusing and frustrating. If there is a way I can advocate for first-class Bazel support - a Google Group, perhaps (I'm in Firebase's Alpha programs, etc), please let me know. I find this to be a deep and meaningful gap in Google's developer strategy that has remained for so long, it can't have been noticed.

[michaeleisel]

+1 for this. Uber, Lyft, Spotify, Pinterest, and Snapchat are all either on Bazel or actively migrating to it. Although there are a few big apps still using Buck, going forwards Bazel is the choice for iOS at scale. Many third-party libraries are straightforward to move to Bazel, e.g. the popular MarqueeLabel library with its one Swift file, but Firebase's complicated dependency graph and inconsistent library structures makes that very difficult. If Firebase really wants to support app development at scale, they'll need to make it easy to use Bazel.

Firebase could either lock down the Podfiles to allow just a subset of their features and release the specifics of how it's locked down, or use some other format (e.g. Bazel BUILD files or something new) and generate the Podfiles from there. If they wanted, they wouldn't even need to do full Bazel integration, just use a format that's easy for someone to write a converter for, and let the open-source community do the rest.

[paulb777]

Firebase's file structure and build system has gotten much more consistent over the last year as we've added support for both podspec and SwiftPM driven builds. Some details at https://github.com/firebase/firebase-ios-sdk/blob/master/AddNewPod.md. It should be feasible to write a converter and we'd be open to PRs to make the structure more canonical.

[fisheye-123]

+1 for bazel integration

[sgammon]

we have been able to approximate the behavior we want here with some naive macros that simply reference ios-i386* or ios-armv7* based on Bazel's dev/opt state.

in combination with some other flags, we were able to get it to build locally - but we're in development, so no word on production-quality builds yet.

.bazel.rc

## iOS-related settings
build --apple_platform_type=ios
build --ios_simulator_version=13.6
build --ios_simulator_device="iPhone 11"
build --apple_generate_dsym=true
build --apple_bitcode=embedded
build --enable_apple_binary_native_protos=true

[sgammon]

@paulb777 being "open to PRs" suggests you are asking the community to write this. is that firebase's position?

considering Google is the author, owner, or both, of Firebase, Bazel, and nearly all of the constituent tooling (i.e. rules_apple, rules_swift are mainline projects), does it make sense to expect the community to implement this?

[sgammon]

politely, could you guys do it instead? i mean most of us in this thread are probably paying for firebase. thanks

[paulb777]

@sgammon Sorry, my statement above about the prioritization of Bazel support still stands. Firebase aspires to meet developers where they're at and for Apple developers that typically means Xcode, Swift Package Manager, CocoaPods and/or Carthage.

Another approach for Bazel might be to integrate with the binary distribution to avoid the complexity of building?

[sgammon]

@paulb777 i apologize, this is just a very frustrating issue. i disagree with your implied characterization that Bazel is not "where [developers are] at."

here is a short list of companies that have adopted Bazel, in some cases for iOS. i imagine many of these companies have the internal resources to write their own rules. not everyone does and firebase has typically seen fit to level that playing field where possible. obviously Bazel is written by Google and now so is Firebase.

• Pinterest (they wrote PodToBUILD and XCHammer)
• Adobe
• Asana
• Android
• Uber
• Lyft
• Wix
• Huawei
• LinkedIn
• Peloton
• Nvidia
• Redfin
• Twitter
• VMWare
• Etsy
• Spotify
• Snapchat
• Dropbox
• Stripe
• Two Sigma
• Braintree/PayPal
• Palantir
• LINE

[sgammon]

considering there is no endorsed way to do google account authentication on iOS without Firebase SDKs, i imagine the aforementioned companies have written their own shims. these are probably coupled in with internal rules, which is why they have not been open-sourced at some point.

but there is certainly a need, and i'd bet many of those snowflake implementations of Firebase's rules (we ended up writing our own, too), don't see maintenance because someday Google will do this, and when they do, the internal implementations die away - and rightfully so, because it is immensely harder outside of Google/Firebase's code enclave to facilitate this support.

[edias]

Did you manage to overcome this issue @sgammon ? If so, how did you do that?

[wweevv-johndpope]

so did some digging over weekend - the following is BRAIN DUMP of different approaches.
I attempted to use PodToBuild with some success (got the files to checkout - but couldn't wire them up as dependencies). bazel-xcode/PodToBUILD#222

XCFRAMEWORKS - (see updated solution at bottom)
bazelbuild/rules_apple#851 ( do have a look - FirebaseAnalytics/FirebaseCore.xcframework - the infra stuff is out of date )

There is also a way to do ios integration with xcframeworks - you can use carthage to spit out xcframeworks
so a cartfile

carthage build --no-skip-current --use-xcframeworks

and then
bazel run @rules_pods//:update_pods -- --src_root $PWD

but I abandoned this for SPM -
https://chuckgrindel.com/swift-packages-in-bazel/ (THIS IS OUT OF DATE / but I found useful - hat tip to @cgrindel)

the latest code - aug 29th (I just realized Chuck actually wrote the rules for this )

WORKPLACE - THIS DOES NOT WORK - PLEASE HELP IF YOU CAN FIX. TEDIOUS WORKAROUND AT BOTTOM

There's a known issue @pswaminathan - identified here -
cgrindel/rules_spm#147

load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")

http_archive(
    name = "cgrindel_rules_spm",
    sha256 = "03718eb865a100ba4449ebcbca6d97bf6ea78fa17346ce6d55532312e8bf9aa8",
    strip_prefix = "rules_spm-0.11.0",
    urls = [
        "http://github.com/cgrindel/rules_spm/archive/v0.11.0.tar.gz",
    ],
)

load(
    "@cgrindel_rules_spm//spm:deps.bzl",
    "spm_rules_dependencies",
)

spm_rules_dependencies()

load(
    "@build_bazel_rules_swift//swift:repositories.bzl",
    "swift_rules_dependencies",
)

swift_rules_dependencies()

load(
    "@build_bazel_rules_swift//swift:extras.bzl",
    "swift_rules_extra_dependencies",
)

swift_rules_extra_dependencies()


load("@cgrindel_rules_spm//spm:defs.bzl", "spm_pkg", "spm_repositories")

spm_repositories(
    name = "swift_pkgs",
    dependencies = [
        spm_pkg(
            "https://github.com/firebase/firebase-ios-sdk.git",
            from_version = "8.10.0",
            products = ["Firebase"],
        ),
    ],
)

UPDATE

@vikage got it working successfully - here
https://thanhvu.dev/2022/04/16/migrating-ios-project-to-bazel-part-6-tich-hop-firebase-crashlytics/

demo app
https://github.com/vikage/DemoBazel/blob/firebase/Thirdparty/Firebase/BUILD

[jfirebaugh]

Add Figma to the list of companies that would appreciate first class Bazel support in firebase-ios-sdk.

[sgammon]

@edias honestly, no, i wish i had :(

[cgrindel]

FYI. I deprecated rules_spm, replacing it with rules_swift_package_manager. There is a firebase example that should help folks get started with using firebase in Bazel. If you run into any problems, please create an issue.

[sgammon]

big endorsement for @cgrindel's tools, we used them before migrating away from Bazel and they worked really well.

[kornerr]

@sgammon what tool did you migrate to?

It's a shame bazel doesn't support CocoaPods out of the box, the de facto standard for iOS libraries, and specifically Firebase, which is the de facto standard for analytics.

[sgammon]

@kornerr For iOS, I think we just built a totally vanilla XCode project, but this was three years ago now. We decided to use things like Gradle until Google sees fit to fully support Bazel.

The lesson for us, ultimately, was that if we are not on Google's endorsed/enlightened path for OSS, we were guaranteed to Have A Bad Time, one way or another, whether it was this issue, or similar issues with Bazel and frontend (typescript has always been a challenge, and it's impossible to use Closure effectively with modern JS), or Bazel and Docker, or Bazel and Kotlin, or Bazel and Google Cloud, etc.

I realize (as a fan of bazel myself) that this advice is rather sad, but we knew we wouldn't always be in Google's enlightened path, so we dropped Bazel entirely. By "enlightened path," I mean toy apps which are suitable for Firebase in a vanilla XCode project, straight out of the documentation, or nothing at all. There is no more advanced adoption path which is endorsed and supported by Google.

This problem arises from Google's internal structure and motivations, and how that structure meets the open source world. If Google made a choice to release enough OSS Bazel support and provide an endorsed adoption path, this would not be a problem. But, as it is, you are meant to consume libraries produced by Bazel, and there is really no easy way to climb up the stack and participate at the level of Google's Bazel without needing code which is unreleased.

If you follow my GitHub PR history, you'll find probably hundreds of PRs trying to get this entire stack to work, over the course of years. I really did try. This issue is just one of many, spread across different languages and teams at Google. Every single time, I ran into this; it isn't isolated to Firebase (to their credit), but it is as bad here as it gets.

I've had Googlers take me to coffee and tell me they tried to fix it, and couldn't. They ended up leaving Google in many cases, finding no other recourse. So they do know about it, they can solve it, they just... won't.

Truthfully, I thought iOS and Firebase would be an exception, because it is so key to the early stages of Google Cloud's funnel, and because Firebase has always been a champion for the little guy. But this issue being open for three years now clearly demonstrates that is not the case, and today I would not use Firebase at all because of this issue.

Bazel's team is not technically part of Cloud (as Firebase is) or Google proper. It is part of this sort of middle-child organization called Google Developers, and it is seen as an open source ecosystem enhancement, not a revenue driver, so that's probably the origin of the issue; in other words, there is no incentive for any single person inside Google to help you on this. Again, I'm sorry to be giving you this advice and long-winded rant, but my hope is that it saves you a whole lot of time.