Update iOS cinterop binding from firebase-ios-sdk 11.8.0 to a current 12.x

[CohesionBrew]

Summary

The iOS cinterop bindings are generated against firebase-cocoapods = "11.8.0" (in gradle/libs.versions.toml). That value is unchanged on master and in the latest release v2.5.0 (2026-05-21), while firebase/firebase-ios-sdk is now at 12.15.0 (2026-06-16) — the entire 12.x line has shipped since 11.8.0 (released early 2025).

Because the binding is exact rather than a range, consumers must pin their Podfile's Firebase/* pods to 11.8.0 to match. Pairing the bindings with newer pods (we tested 12.10.0) produces runtime NSExceptions, so the pin is a hard requirement, not a floor. The practical effect is that apps depending on this SDK are frozen ~18 months behind on the native Firestore/Auth/gRPC-C++/BoringSSL stack and can't pick up the security and bug fixes shipped across firebase-ios 12.x.

Ask

Could the iOS cinterop binding be regenerated against a current firebase-ios-sdk 12.x (ideally the latest 12.15.0) and released? Even a single 12.x-pinned release would let downstream apps move their Podfiles forward in lockstep.

Context / offer to help

• Consumer Podfile currently must pin Firebase/* '11.8.0' to match the 2.4.0 / 2.5.0 cinterop.
• Firebase Android BOM already tracks current (33.x on master), so this is specifically the iOS CocoaPods binding that's behind.
• Happy to test a pre-release against a real Compose Multiplatform app (anonymous / Apple / Google auth + Firestore one-shot & realtime + AppCheck + RemoteConfig) if that would help validate a bump.

Thanks for maintaining this — the KMP-everywhere Firestore story is exactly what we needed.

[herrbert74]

Thanks for tracking this — we’re hitting the same constraint from another angle and would really appreciate a 12.x cinterop bump when you can prioritize it.

We’re on a Compose Multiplatform app that uses:

dev.gitlive:firebase-auth 2.5.0 (cinterop still built against Firebase iOS 11.8.0)
KMPNotifier 2.0, which declares SwiftPM firebase-ios-sdk exact 12.14.0 for Messaging
KMPAuth 2.5 today; trying 3.0 (alpha) adds a SwiftPM Firebase pin of from 11.8.0 (i.e. <12)
On CocoaPods this was easier to paper over. With Kotlin’s SwiftPM import the graph is strict, so under KMPAuth 3.0 the 11.8-range and exact 12.14 requirements cannot resolve together. We’re stuck between:

staying aligned with GitLive’s 11.8 binding (and avoiding the runtime NSExceptions you reported with 12.x), or
taking 12.14 for KMPNotifier / newer Firebase fixes — which we already link for Messaging — and accepting the mismatch with GitLive’s cinterop.
Your note that pairing the current bindings with 12.x is a hard runtime requirement (not just a soft pin) matches the packaging conflict we’re seeing. A release regenerated against a current 12.x (ideally aligning with something like 12.14+/12.15) would unblock apps that need both GitLive Auth and other libraries already on Firebase 12 via SwiftPM.

Happy to test a GitLive pre-release rebuilt against Firebase iOS 12.x on our current stack (GitLive Auth 2.5 + KMPNotifier Messaging on Firebase 12.14). We can’t yet validate the same combo under KMPAuth 3.0, because its SwiftPM pin conflicts with KMPNotifier’s exact 12.14.0 and the graph fails to resolve.

Thanks again for maintaining this.