[Bug]: [iOS] Navigation SDK init/quota retry loop pins the main thread; React Native's Settings module and addMarker's temporary GMSMarker add to the cost
I maintainer di solito rispondono entro 5 giorni
@illuminati1911 ci sta già lavorando.
Dal 26/10/2026.
Valutazione
Questa issue non è ancora stata valutata.
Descrizione
Is there an existing issue for this?
- I have searched the existing issues
Description of the bug
Summary
On iOS, Navigation SDK 11.1.0 can get stuck retrying its init/quota request with no backoff, on the main thread. While that happens an app uses 100–160 % CPU even when idle, and the UI is sluggish. I've reported the SDK bug to Google, with a native repro: https://issuetracker.google.com/issues/577830531
I'm opening this here because two things make it worse in a React Native app, and one of them is in this wrapper.
Environment
@googlemaps/react-native-navigation-sdk0.17.3- React Native 0.87.1, New Architecture
- Navigation SDK for iOS 11.1.0, Maps SDK for iOS 11.1.0
- iPhone 15 Pro Max, iOS 27.0.1
What triggers the loop
In a native app (no React Native), any GMSNavigationServices call while the terms aren't accepted starts it. Even areTermsAndConditionsAccepted does, and so does the terms dialog while it's open. Accepting the terms stops it. In our React Native app we also saw it with the terms already accepted: on a network whose DNS blocks a Google endpoint (a Pi-hole), and after repeatedly opening and closing a screen with map views.
Through this wrapper, areTermsAccepted(), showTermsAndConditionsDialog() and init() reach those calls, so an app that checks the terms early (for example when a screen mounts) can start the loop with nothing on screen.
Native repro app: https://github.com/filipesteves/navsdk-ios-init-retry-repro
Why it's worse in React Native
1. React Native's Settings module. Each retry writes NSUserDefaults several times (about 1,000 writes a second). React Native's RCTSettingsManager observes NSUserDefaultsDidChangeNotification, and on each one it serialises the whole defaults dictionary and sends it to JS. In Time Profiler that was about half of the main-thread samples during the loop. This is React Native core, not this wrapper, but anyone using the wrapper pays it.
2. addMarker on an existing id builds a temporary GMSMarker. In NavViewModule.mm, addMarker always creates a new GMSMarker (with the icon from imgPath), then NavViewController addMarker:visible:result: copies its properties onto the existing marker. Each new GMSMarker writes NSUserDefaults once, with or without an icon. So every addMarker call is a defaults write, and a full Settings round-trip to JS.
Measured in the native repro, re-adding 10 markers every 0.25 s (40 calls/s):
| How existing markers are updated | defaults writes/s |
|---|---|
Like the wrapper (temporary GMSMarker, then copy) |
40 |
| Directly on the existing marker | 0 |
Marker updates didn't start the retry loop in our tests (11,200 calls and 28 map views over 7.8 minutes, no loop), but they add steady main-thread work in apps that redraw markers often.
Suggestions
- When
addMarkergets an id that already exists, update that marker in place without building a temporaryGMSMarker. - Consider a note in the docs that, on iOS, calling
areTermsAccepted()/init()before the user is about to accept the terms can trigger the SDK's retry loop (until Google fixes the linked bug).
I can open a PR for the first one if that would help.
iOS Platform
Affected
Android Platform
Not verified
React Native version
0.87.1 (New Architecture)
React version
19.2.3
Package version
0.17.3
Native SDK versions
- I haven't changed the version of the native SDKs
React Native Doctor Output
Common
✓ Node.js - Required to execute JavaScript code
✓ npm - Required to install NPM dependencies
✓ Watchman - Used for watching changes in the filesystem when in development mode
✓ Metro - Required for bundling the JavaScript code
Android
✖ Adb - No devices and/or emulators connected. Please create emulator with Android Studio or connect Android device.
✓ JDK - Required to compile Java code
✓ Android Studio - Required for building and installing your app on Android
✖ ANDROID_HOME - Environment variable that points to your Android SDK installation
✓ Gradlew - Build tool required for Android builds
✖ Android SDK - Required for building and installing your app on Android
- Versions found: N/A
- Version supported: 37.0.0
iOS
✓ Xcode - Required for building and installing your app on iOS
✓ Ruby - Required for installing iOS dependencies
✓ CocoaPods - Required for installing iOS dependencies
✓ .xcode.env - File to customize Xcode environment
Errors: 3
Warnings: 0
(The 3 errors are Android tooling on this machine; the issue is iOS-only.)
Steps to reproduce
Marker writes (no retry loop needed):
- Show a
MapVieworNavigationViewwith ~10 markers. - Call
addMarkeragain for the same ids every 250 ms (as an app that redraws markers on each location update does). - Observe
NSUserDefaultsDidChangeNotificationon iOS: one peraddMarkercall (40/s here). With React Native's Settings module, each one sends the whole defaults dictionary to JS.
Retry loop (native SDK bug, linked above):
- Fresh install, terms not accepted.
- Call
navigationController.areTermsAccepted()(or show the terms dialog and leave it open). - Watch CPU in Xcode: 40–160 % while idle until the terms are accepted.
Native repro of both (no React Native): https://github.com/filipesteves/navsdk-ios-init-retry-repro
Expected vs Actual Behavior
Expected: updating an existing marker doesn't write NSUserDefaults, and an idle app stays near 0 % CPU.
Actual: each addMarker call on an existing id writes NSUserDefaults once. Measured in the native repro, re-adding 10 markers every 0.25 s:
| How existing markers are updated | defaults writes/s |
|---|---|
Like the wrapper (temporary GMSMarker, then copy) |
40 |
| Directly on the existing marker | 0 |
Combined with the SDK's retry loop, the app sat at 100–160 % CPU while idle (Time Profiler: GMSNavigationQuotaService sendNavigationInitRequestWithHandler: → GMSDASHProtobufferRequest scheduleRetryIfApplicableForResponse:error:connection:, plus -[RCTSettingsManager userDefaultsDidChange:]).
Code Sample
import { useEffect } from 'react';
import { useNavigation } from '@googlemaps/react-native-navigation-sdk';
// 1. Re-adding markers with existing ids: one NSUserDefaults write per call on iOS.
function redrawMarkers(mapViewController) {
const timer = setInterval(() => {
for (let i = 0; i < 10; i++) {
mapViewController.addMarker({
id: `marker-${i}`,
position: { lat: 37.7793 + 0.006 * Math.sin(i), lng: -122.4193 + 0.008 * Math.cos(i) },
imgPath: 'custom_marker',
});
}
}, 250);
return () => clearInterval(timer);
}
// 2. Checking the terms before they're accepted starts the SDK's retry loop (native bug).
function TermsCheck() {
const { navigationController } = useNavigation();
useEffect(() => {
navigationController.areTermsAccepted();
}, [navigationController]);
return null;
}
Additional Context
- Navigation SDK for iOS 11.1.0, Maps SDK for iOS 11.1.0; iPhone 15 Pro Max, iOS 27.0.1; Xcode 27.0, Debug build.
- Google issue for the retry loop: https://issuetracker.google.com/issues/577830531
- Marker updates alone didn't start the retry loop in our tests (11,200 calls and 28 map views over 7.8 minutes).
- Related, in the native SDK: every
GMSMapView setPadding:call also writesNSUserDefaults, even with an unchanged value. - Happy to open a PR for the in-place marker update.
- Lingua principale
- TypeScript
- Stelle
- 226
- Fork
- 39
- Merge medio
- 1g 20h
- PR unite (30g)
- 7
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di googlemaps/react-native-navigation-sdk
-
[Support Request]: Status of Expo config plugin release (prebuild fails on 0.19.0)Forse già presa @jokerttu l’ha presa 1 giorno fa. Aperta
googlemaps/react-native-navigation-sdk#711 · 1 assegnatario ·
I maintainer di solito rispondono entro 5 giorni
-
[Bug]: In-navigation notification can't be stoppedForse già presa @jokerttu l’ha presa 8 giorni fa. Apertatriage me type: bug
googlemaps/react-native-navigation-sdk#696 · 1 assegnatario ·
I maintainer di solito rispondono entro 5 giorni
-
[Bug]: iOS crash in GMSObjectDataCache Core Data save (fatal optimistic locking failure)Forse di nuovo libera @illuminati1911 l’ha presa 60 giorni fa e non c’è nessuna pull request aperta. Apertanative sdk issue
googlemaps/react-native-navigation-sdk#647 · 1 commento · 1 assegnatario ·
I maintainer di solito rispondono entro 5 giorni
-
[Bug]: CarPlay map view never sets GMSMapViewOptions.screen, so the navigation header and footer are sized for the phoneForse di nuovo libera @jokerttu l’ha presa 73 giorni fa e non c’è nessuna pull request aperta. Aperta
googlemaps/react-native-navigation-sdk#640 · 4 commenti · 1 reazione · 1 assegnatario ·
I maintainer di solito rispondono entro 5 giorni
-
[Bug]: CarPlay Simulator crashes on iOS versions > 26.3Forse di nuovo libera @jokerttu l’ha presa 155 giorni fa e non c’è nessuna pull request aperta. Apertapriority: p2 type: bug
googlemaps/react-native-navigation-sdk#607 · 1 commento · 2 assegnatari ·
I maintainer di solito rispondono entro 5 giorni
Tutte le issue di googlemaps/react-native-navigation-sdk
Issue simili
-
pending close triaging
Difficoltà 1/5 1-3 ore Idoneità per principianti 74/100
anomalyco/opencode#63090 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
ai-driven-qa bug claude Cosmetic
Difficoltà 2/5 1-3 ore Idoneità per principianti 74/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
I maintainer di solito rispondono entro 1 giorno
-
ai-driven-qa bug claude Minor
Difficoltà 2/5 1-3 ore Idoneità per principianti 76/100
linagora/twake-mail-admin#609 ·
I maintainer di solito rispondono entro 1 giorno