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