Add Linking.openNotificationSettings() - #58487
Open
plrdev wants to merge 1 commit into
Open
Conversation
Add `Linking.openNotificationSettings()` which opens the app's notification settings screen in the system Settings app. - iOS: uses `UIApplicationOpenNotificationSettingsURLString` (iOS 15.4+), falling back to `UIApplicationOpenSettingsURLString` on 15.1-15.3. - Android: launches `Settings.ACTION_APP_NOTIFICATION_SETTINGS` with `Settings.EXTRA_APP_PACKAGE` (API 26+), falling back to `ACTION_APPLICATION_DETAILS_SETTINGS` on API 24-25. Includes TurboModule spec entries, legacy and generated TS types, ReactAndroid.api entry, jest-preset mock, RNTester example, a JS dispatch test and Robolectric tests for the Android module. Changelog: [GENERAL] [ADDED] - Add Linking.openNotificationSettings() to open the app's notification settings on iOS (15.4+) and Android (API 26+), falling back to the app settings page on older OS versions Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
|
Warning JavaScript API change detected This PR commits an update to
This change was flagged as: |
plrdev
marked this pull request as ready for review
September 11, 2026 14:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
Linking.openSettings()opens Settings → Your App. Both platforms have had an official, App-Review-safe way to land one level deeper, on the app's notification settings, for years, but React Native does not expose either:UIApplication.openNotificationSettingsURLStringSettings.ACTION_APP_NOTIFICATION_SETTINGSwithSettings.EXTRA_APP_PACKAGEToday apps either reach for undocumented
prefs:root=/App-Prefs:URLs on iOS (a known App Store rejection risk), or hand-rollLinking.sendIntenton Android (the existing RNTester Linking example does exactly this). Sending users to the right screen after a denied notification permission is a very common flow, so this belongs in core next toopenSettings(), which was added the same way in #23965.This PR adds
Linking.openNotificationSettings(): Promise<void>:UIApplicationOpenNotificationSettingsURLStringon iOS 15.4+, guarded with@availablesince the minimum deployment target is 15.1. On 15.1–15.3 it falls back toUIApplicationOpenSettingsURLString. TheopenURL+ resolve/reject logic is shared withopenSettingsvia a small private helper.ACTION_APP_NOTIFICATION_SETTINGSwithEXTRA_APP_PACKAGEon API 26+, and falls back toACTION_APPLICATION_DETAILS_SETTINGSon API 24–25. Intent flags matchopenSettings. The shared intent-building / activity-start code is factored into private helpers reused byopenSettings.Linking, TurboModule spec entries forNativeLinkingManagerandNativeIntentAndroid, legacy.d.tstypes, regeneratedReactNativeApi.d.tssnapshot,ReactAndroid.apientry, jest-preset mock, RNTester example.Linking-test.jscovering platform dispatch foropenSettings/openNotificationSettings; new Robolectric tests inIntentModuleTestcovering the API 26+ intent, the API 25 fallback (@Config(sdk = [25])), and rejection when there is no current activity.Fallback rather than rejection on old OS versions was chosen deliberately: callers want "take the user as close as possible to the notification toggle", and the general app settings page is that on those OS versions. Behavior is documented in the JSDoc.
Changelog:
[GENERAL] [ADDED] - Add
Linking.openNotificationSettings()to open the app's notification settings on iOS (15.4+) and Android (API 26+), falling back to the app settings page on older OS versionsTest Plan:
All run locally on macOS (Xcode 26.3, Zulu JDK 17, Node 22.23) against
main:Android (RNTester, Pixel 9 Pro API 35 emulator): built and installed via
:packages:rn-tester:android:app:installDebug. Linking → "Open notification settings" → Settings opens directly onSettings$AppNotificationSettingsActivityfor RNTester.iOS (RNTester, iPhone 17 Pro, iOS 26.3 simulator): built via
xcodebuild -workspace RNTesterPods.xcworkspace -scheme RNTester, no warnings fromRCTLinkingManager.mm. CallingLinking.openNotificationSettings()brings the Settings app to the foreground and the promise resolves. Note: on the iOS Simulator bothopenSettings()andopenNotificationSettings()land on the Settings root screen (the Simulator's Settings app does not expose third-party app pages), so the exact landing page could only be confirmed on Android; on a device iOS 15.4+ resolvesUIApplicationOpenNotificationSettingsURLStringto Settings → App → Notifications per Apple's documentation.Not tested: the iOS 15.1–15.3 and Android API 24–25 fallback paths on a device/emulator (no such runtimes available locally); the Android fallback is covered by the
@Config(sdk = [25])Robolectric test.