chore: bump react-native-screens 4.10.0 → 4.16.0

[janicduplessis]

What changed (plus any additional context for devs)

Bumps react-native-screens from 4.10.0 to 4.16.0 (Expo 54's pinned range). No patch needed.

We only directly import enableScreens and FullWindowOverlay, neither of which changed. React-navigation depends on this library heavily under the hood, so it is foundational for the whole navigation stack. Between 4.10 and 4.16 the library added formSheet / pageSheet presentations, experimental native bottom tabs (gated behind flags we don't enable), iOS 26 compatibility, and edge-to-edge integration. Everything RN-version-specific is gated to new arch via CMake guards, so on our old-arch build there is no coupling to RN 0.79 vs 0.81. 4.14.0 drops RN < 0.79 support — still fine for us.

Why not 4.24.0 (latest)

Initially tried 4.24.0 but the Android CI build failed for two reasons that both trace back to newer-RN assumptions:

1. compileSdk mismatch — 4.24 pulls in androidx.core:core-ktx:1.17.0 transitively, which requires compileSdk=36. We're still on 35 until the RN 0.81 bump PR lands.
2. Codegen failure — ScreenStackHeaderConfigNativeComponent.ts has an onAttached prop whose type resolves to undefined under our current codegen.

4.16.0 avoids both issues and matches Expo 54's ~4.16.0 pin.

MainActivity.kt: migrate to RNScreensFragmentFactory

4.16 introduced a scoped alternative (software-mansion/react-native-screens#3089) to the long-standing super.onCreate(null) workaround (software-mansion/react-native-screens#17): install an RNScreensFragmentFactory on the fragment manager and it removes only RNS fragments when Android tries to restore them, so other fragment restoration still works.

Swapped the old super.onCreate(null) for supportFragmentManager.fragmentFactory = RNScreensFragmentFactory() followed by super.onCreate(savedInstanceState). We don't have other native fragment consumers today, but adopting the upstream-recommended pattern means we're not stuck on a workaround any reviewer has to re-derive next time they touch this file.

Verified against our Mobile React Native 0.81 Upgrade Plan. Extracted from #7366 (RN 0.81 bump) so it can land independently.

Screen recordings / screenshots

N/A — no visual changes expected.

What to test

• Quick smoke test of app navigation
• Rotate device or trigger process death (enable "Don't keep activities" in developer options) and reopen the app — navigation should restore without duplicate screens

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	npm/​react-native-screens@​4.10.0 ⏵ 4.16.0

View full report

[github-actions]

🧪 Flashlight Performance Report (AWS Device Farm)

🔀 Commit: 8c95ce4

📎 View Artifacts

Metric	Current	Δ vs Baseline
Time to Interactive (TTI)	5448 ms	⚪ +28.8 ms (+0.5%)
Average FPS	56.92	🟢 +0.6 (+1.0%)
Average RAM	380.0 MB	🟢 -16.7 MB (-4.2%)

[github-actions]

Launch in simulator or device for 3d5d9eb

[github-actions]

Launch in simulator or device for 1e7c47e

[olerass]

LGTM overall. Small finding from robot Ole (my local AI eval):

In MainActivity.kt:21: the super.onCreate(null) line there is a long-standing workaround for an Android issue (software-mansion/react-native-screens#17) where when Android restores fragments after a config change or process death, react-native-screens' fragments get duplicated -- Android tries to restore them at the same time as React recreates them from JS. Passing null instead of savedInstanceState basically tells Android "skip all fragment restoration", and React re-renders everything fresh. Blunt, but works.

4.16.0 adds a scoped alternative (software-mansion/react-native-screens#3089): a RNScreensFragmentFactory you install on the fragment manager that auto-removes only RNS fragments when Android tries to restore them, so other fragment restoration still works. For brownfield apps that matters; for us afaiu it doesn't -- we don't have any other fragment consumers in native code, and the manifest configChanges intercepts most of the triggering cases anyway. So we're fine staying on the old pattern.

AFAIU this is a nit is that the existing comment ("Pass null here as required by react-native-screens") isn't accurate anymore since it's no longer the only way. Not blocking. Probably worth either a one-line comment update in this PR, or a follow-up to migrate to the factory + note in the PR body that we're intentionally staying on the legacy pattern.

[github-actions]

Launch in simulator or device for 03a34eb

[github-actions]

Launch in simulator or device for 8c95ce4