fix: app crashing due to undefined settings constant accessor

[CalhamJNorthway]

The purpose of this PR is to fix a crash I found yesterday caused by an accessor that is undefined when newer versions of react native have Fabric enabled.

Our Build Setup:
react-native: v0.80.0
@launchdarkly/react-native-client-sdk: v10.1.5

Requirements

• add null coalescing operation to use getConstants to prevent undefined settings object
• still default to old accessor if not undefined

Related issues
I've not seen any related issues yet regarding your repo, though I did find this one Stack Overflow post.

Describe the solution you've provided
The solution I've provided is to use a null coalescing check to fallback to the new getConstants method on native modules if the settings object is undefined.

Describe alternatives you've considered
I searched to see if there are preferred alternatives and did not come up with any other solutions. I am open to feedback on that though :)

---

Note

Low Risk
Small, localized change to iOS locale detection plus an added lint script; low blast radius, with only minor risk of behavior differences in locale resolution on iOS.

Overview
Fixes iOS locale detection in the React Native SDK to avoid crashes on Fabric-enabled apps by falling back from SettingsManager.settings to SettingsManager.getConstants()?.settings when reading AppleLocale.

Adds a lint:fix script to the React Native package to run ESLint with --fix.

^{Written by Cursor Bugbot for commit 0ee1355. This will update automatically on new commits. Configure here.}

---

[kinyoklion]

@CalhamJNorthway Thank you for the PR!

What was the crash you are seeing? While I think that we need an update to reliably be accessing the locale, I don't see anything that was doing anything other than forwarding along the undefined value. Settings was undefined, but the app locale as already being conditionally accessed from it.

NativeModules.SettingsManager?.settings?.AppleLocale

Though there was a previous version where it looked like this:
NativeModules.SettingsManager?.settings.AppleLocale

Which would have crashed.

Thank you,
Ryan

[CalhamJNorthway]

@CalhamJNorthway Thank you for the PR!

What was the crash you are seeing? While I think that we need an update to reliably be accessing the locale, I don't see anything that was doing anything other than forwarding along the undefined value. Settings was undefined, but the app locale as already being conditionally accessed from it.

NativeModules.SettingsManager?.settings?.AppleLocale

Though there was a previous version where it looked like this: NativeModules.SettingsManager?.settings.AppleLocale

Which would have crashed.

Thank you, Ryan

Hey @kinyoklion, thanks for the prompt reply. I can add a little more detail, the issue was actually with the launch darkly client not instantiating correctly when the locale was undefined. You end up getting an error

Error initializing LaunchDarkly: TypeError: Cannot read property 'ldApplication' of undefined

Which after some further digging, I'm assuming was caused by the error below bubbling up to a higher error boundary

Error initializing LaunchDarkly: TypeError: Cannot read property 'AppleLocale' of undefined

Also for posterity, I have validated this fix with a node module patch on our application.
If you would like me to reproduce it with some screenshots I can do that tomorrow and post them here as a reply!

[joker23]

Thanks @CalhamJNorthway for the PR! Sorry for the delay in response, but I think this PR would be ready to merge after addressing my comments.

Fixed

[cursor]

Bug: Incorrect accessor path for getConstants() in Fabric

The fallback accessor NativeModules.SettingsManager?.getConstants()?.settings likely has an incorrect property path. In React Native's new Fabric architecture, getConstants() typically returns constants directly at the top level (e.g., {AppleLocale: 'en_US'}), not nested under a settings property. This means getConstants()?.settings would return undefined, causing AppleLocale to never be found even when available through getConstants(). The accessor likely needs to be getConstants()?.AppleLocale or getConstants() should replace the entire settings variable.

 

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.}

[cursor]

Missing optional chaining on getConstants function call

High Severity

The code NativeModules.SettingsManager?.getConstants()?.settings will throw a TypeError if SettingsManager exists but getConstants is not a function. The optional chain before getConstants() only guards against SettingsManager being nullish, not getConstants being undefined. In older React Native versions without Fabric/TurboModules, getConstants may not exist on SettingsManager. The fix is to use getConstants?.() to safely handle the case where the method doesn't exist.

 

[devin-ai-integration]

Devin Review found 1 potential issue.

View issue and 2 additional flags in Devin Review.

[devin-ai-integration]

🟡 iOS locale fallback to getConstants is skipped when SettingsManager.settings exists but lacks AppleLocale

On iOS, the code intends to fall back to SettingsManager.getConstants().settings for Fabric-enabled apps, but it uses nullish coalescing on the whole settings object. If NativeModules.SettingsManager.settings exists (non-null/undefined) but does not contain AppleLocale (common in some RN/Fabric setups), the fallback is never attempted and the exported locale becomes undefined.

Actual: locale resolves to undefined even though getConstants().settings.AppleLocale may be available.
Expected: fall back to getConstants when AppleLocale is missing, not only when the settings object itself is null/undefined.

Click to expand

Current logic:

const settings =
  NativeModules.SettingsManager?.settings ??
  NativeModules.SettingsManager?.getConstants()?.settings;
return settings?.AppleLocale;

If settings is {} (or otherwise truthy) but has no AppleLocale, ?? prevents using getConstants().

A safer pattern is to coalesce the property:

return (
  NativeModules.SettingsManager?.settings?.AppleLocale ??
  NativeModules.SettingsManager?.getConstants()?.settings?.AppleLocale
);

Recommendation: Coalesce on AppleLocale (or check for its presence) rather than coalescing the entire settings object, so the getConstants() fallback runs when settings exists but lacks AppleLocale.

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[joker23]

Thanks again for bringing this to our attention! After some deliberation, we've decided that we will need a major version overhaul to adequately support the new architecture. For now I will close this PR with the anticipation that our changes will probably deprecate this logic.