Ugh. Thanks for all your work on those issues though. It sounds like @cgrindel got somewhere with it.
While I understand the frustration, I see package managers and Bazel as quite distinct approaches, and I'm not surprised that they are incompatible. There shouldn't be anything incompatible between Firebase itself and Bazel – I can assure you that Bazel is used to build wildly esoteric things at Google – but the Cocoapods/SPM layer is sort of fighting an uphill battle because Bazel is built on the assumption that it's building everything itself.
I work on a very large mobile app that is built with Bazel, and can attest to how worth it the experience is at scale, but I realise it takes a lot of doing to make it work, and that doesn't pay off until a certain point.
I'm sorry I'm not able to help with a fix. That's down to my lack of expertise in the specifics of iOS builds.
I get the frustration, I really do. It makes sense that different Google technologies should work with each other like in this case, but I can see why this sort of thing slips through the cracks when the teams are so far removed from each other.
Regarding Bazel's ability to do this, I can't say for sure, but I see a common pattern in Bazel usage outside of Google where users expect it to work at a higher level than it does. At a fundamental level if you can do it on the command line by running commands and moving files around, then Bazel can do it (hermetically, reproducibly, etc). Big Bazel deployments build up a lot of build definitions that handle all these things and abstract away the details, and these may be what's missing.
Anecdotally, I work on a very large Android app, and it's all built with Bazel rules that are many layers deep of customisation. At the bottom somewhere is a `java_binary` rule or something like that from Bazel itself, but there's a lot of customisation to make it work for us. It sounds like this would be necessary to get Firebase working. Ultimately though if Xcode can build it, Bazel can script it.
As for Cocoapods/SPM etc, the reason I said these were at odds with the Bazel process is because Bazel is designed for a world without package managers where you just have all the code in your monorepo with the appropriate BUILD files, because this is how Google works. It sounds like there is tooling to work around this and get the code into the Bazel cache, but it's unlikely that automatically generating BUILD files is always going to get it right.
