firebase-ios-sdk: Can't build Firebase via PodToBUILD/Bazel

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

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

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

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.

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

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). https://github.com/pinterest/PodToBUILD/issues/222

XCFRAMEWORKS - (see updated solution at bottom) https://github.com/bazelbuild/rules_apple/issues/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 - https://github.com/cgrindel/rules_spm/issues/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