[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
メンテナーはふだん 5 日以内に返信
@illuminati1911 がすでに取り組んでいます。
2026年10月26日 から。
評価
この issue はまだ評価されていません。
説明
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.
- 主要言語
- TypeScript
- スター
- 226
- フォーク
- 39
- 平均マージ
- 1日 20時間
- マージ済み PR(30日)
- 7
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートあり
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
googlemaps/react-native-navigation-sdk のほかの issue
-
[Support Request]: Status of Expo config plugin release (prebuild fails on 0.19.0)対応中かも @jokerttu が 1 日前に担当しました。 オープン
googlemaps/react-native-navigation-sdk#711 · 担当者 1 名 ·
メンテナーはふだん 5 日以内に返信
-
[Bug]: In-navigation notification can't be stopped対応中かも @jokerttu が 8 日前に担当しました。 オープンtriage me type: bug
googlemaps/react-native-navigation-sdk#696 · 担当者 1 名 ·
メンテナーはふだん 5 日以内に返信
-
[Bug]: iOS crash in GMSObjectDataCache Core Data save (fatal optimistic locking failure)再び着手できるかも @illuminati1911 が 60 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンnative sdk issue
googlemaps/react-native-navigation-sdk#647 · コメント 1 件 · 担当者 1 名 ·
メンテナーはふだん 5 日以内に返信
-
[Bug]: CarPlay map view never sets GMSMapViewOptions.screen, so the navigation header and footer are sized for the phone再び着手できるかも @jokerttu が 73 日前に担当しましたが、オープン中のプルリクエストはありません。 オープン
googlemaps/react-native-navigation-sdk#640 · コメント 4 件 · リアクション 1 件 · 担当者 1 名 ·
メンテナーはふだん 5 日以内に返信
-
[Bug]: CarPlay Simulator crashes on iOS versions > 26.3再び着手できるかも @jokerttu が 155 日前に担当しましたが、オープン中のプルリクエストはありません。 オープンpriority: p2 type: bug
googlemaps/react-native-navigation-sdk#607 · コメント 1 件 · 担当者 2 名 ·
メンテナーはふだん 5 日以内に返信
googlemaps/react-native-navigation-sdk の issue をすべて見る
似ている issue
-
pending close triaging
難易度 1/5 1〜3時間 初心者へのやさしさ 74/100
anomalyco/opencode#63090 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
ai-driven-qa bug claude Cosmetic
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
メンテナーはふだん 1 日以内に返信
-
ai-driven-qa bug claude Minor
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
linagora/twake-mail-admin#609 ·
メンテナーはふだん 1 日以内に返信