[Feature request]: Resolve GoogleNavigation via Swift Package Manager — the CocoaPods pod stops at 10.15.0 and conflicts with SPM-based libraries

[lucavanv]

Summary

@googlemaps/react-native-navigation-sdk resolves its native dependency through CocoaPods
(s.dependency "GoogleNavigation", "10.13.0" in 0.16.3). Two problems follow from that:

1. The pod is behind and appears to be end-of-line. CocoaPods trunk carries
   GoogleNavigation up to 10.15.0, while 11.0.0 is the current release in
   googlemaps/ios-navigation-sdk
   and is not published to CocoaPods. So the wrapper currently has no route to 11.x.
2. The pod's static linkage conflicts with libraries that resolve their native dependencies
   via SPM. Concretely, any app that combines this library with react-native-firebase
   >= 26.1.0 cannot complete pod install (details and both error messages below).

Is SPM resolution planned for this wrapper, and is there a rough timeline we could plan against?

Why this is time-sensitive

From the Navigation SDK for iOS release notes,
under the August 18, 2025 entry:

CocoaPods is in maintenance mode as of 8/18/2025 and we won't release more versions of CocoaPods after Q2 2026.

Swift Package Manager has been available for a while — from the
Google Maps Platform announcement:

Swift Package Manager support is available for Google Maps Platform SDKs beginning with version 8.3.1 of the Maps SDK for iOS, version 8.3.0 of Places SDK for iOS, and version 5.3.1 of the Navigation SDK for iOS.

Current pod versions can be checked with:

curl -s https://trunk.cocoapods.org/api/v1/pods/GoogleNavigation | jq '.versions[].name'

At the time of writing this returns 10.15.0 as the highest version, with no 11.x.

The concrete conflict with react-native-firebase

react-native-firebase 26.1.0 resolves the Firebase Apple SDK via SPM by default and requires
dynamic linkage. GoogleNavigation.xcframework as distributed through CocoaPods is a static
archive:

$ file Pods/GoogleNavigation/Frameworks/GoogleNavigation.xcframework/ios-arm64_x86_64-simulator/GoogleNavigation.framework/GoogleNavigation
Mach-O universal binary with 2 architectures:
  [x86_64:current ar archive random library] [arm64]

Because CocoaPods' use_frameworks! is an all-or-nothing decision per target, the two cannot
coexist. Both directions fail at pod install:

With static linkage (use_frameworks! :linkage => :static):

[react-native-firebase] SPM + static linkage is not supported (target(s): Pods-<App>).

firebase-ios-sdk's Swift Package only ships dynamic library products, so
`use_frameworks! :linkage => :static` causes every react-native-firebase pod that resolves
Firebase via SPM to embed its own copy of the same Firebase frameworks -- this produces
duplicate-symbol linker errors at build time instead of a clear error here.

With dynamic linkage (use_frameworks! :linkage => :dynamic):

The 'Pods-<App>' target has transitive dependencies that include statically linked binaries:
(.../Pods/GoogleNavigation/Frameworks/GoogleNavigation.xcframework)

The only workaround today is $RNFirebaseDisableSPM = true, which keeps Firebase on CocoaPods —
i.e. it opts out of the migration Firebase is asking everyone to make before their own CocoaPods
cutoff. That is a stopgap, not a solution.

Environment

@googlemaps/react-native-navigation-sdk	0.16.3
GoogleNavigation pod (pinned by podspec)	10.13.0
@react-native-firebase/*	26.1.0
react-native	0.86.2
expo	57.0.11 (prebuild / dev client)
CocoaPods	1.16.2
Xcode	26.6
iOS deployment target	16.4

Reproduces on a clean expo prebuild --clean --platform ios.

Suggested approach

React Native provides an spm_dependency podspec helper that lets a podspec declare an SPM
dependency while still being consumed through CocoaPods autolinking.

react-native-firebase uses exactly this, with a CocoaPods fallback when the helper is unavailable
(its fallback message states "SPM not available (React Native < 0.75)"). The pattern, from
firebase_spm.rb in that project:

if defined?(spm_dependency) && !rnfirebase_spm_disabled?
  spm_dependency(spec,
    url: 'https://github.com/firebase/firebase-ios-sdk.git',
    requirement: { kind: 'upToNextMajorVersion', minimumVersion: version },
    products: spm_products
  )
else
  spec.dependency pod, version   # CocoaPods fallback
end

Applying the same pattern here, pointing at https://github.com/googlemaps/ios-navigation-sdk,
would keep older React Native versions working via the fallback while unblocking 11.x and
coexistence with SPM-based libraries.

An opt-out global (as $RNFirebaseDisableSPM does) would be a useful escape hatch during the
transition.