iOS Release crash on tab select: nil selectedScreenKey reaches -[RNSTabsNavigationState cloneState] (stringWithString:nil)

[genchats]

Description

In Release builds on iOS 26, selecting a bottom tab can crash the app with NSInvalidArgumentException inside -[RNSTabsNavigationState cloneState]:

2   Foundation                     -[NSPlaceholderString initWithString:] + 940 (NSString.m:2327)
3   Foundation                     +[NSString stringWithString:] + 32 (NSString.m:213)
4   app                            -[RNSTabsNavigationState cloneState] + 76 (RNSTabsNavigationState.mm:17)
5   app                            -[RNSTabBarController progressNavigationState:withOrigin:] + 124 (RNSTabBarController.mm:648)
6   app                            -[RNSTabBarController updateNavigationStateOnModelUpdate] + 48 (RNSTabBarController.mm:315)
7   app                            -[RNSTabBarController userDidSelectViewController:] + 96 (RNSTabBarController.mm:355)
8   app                            -[RNSTabBarController tabBarController:didSelectViewController:] + 24 (RNSTabBarController.mm:448)
9   UIKitCore                      -[UITabBarController _setSelectedViewControllerAndNotify:] + 276

Root cause

On tab selection, updateNavigationStateOnModelUpdate derives the key via screenKeyForSelectedViewController → screenKeyForViewController: → getScreenKeyOrNull, which reads self.tabScreenComponentView.screenKey (RNSTabsScreenViewController.mm). That is nil while the selected tab's component view is detached — e.g. while tab triggers are being remounted. In our app, a persisted "show this tab" toggle rehydrates from storage shortly after cold launch and remounts the <NativeTabs.Trigger> list (expo-router); a tab tap landing in that window reliably produces the nil.

Every guard on this path is RCTAssert (progressNavigationState: line ~637, screenKeyForViewController: line ~672), which compiles out of Release builds. So the nil key is silently stored into _navigationState, and the app aborts on the next cloneState call at RNSTabsNavigationState.mm:17 ([NSString stringWithString:nil] throws). Debug builds would have tripped the assert instead, which is presumably why this survived testing.

Still present on main (ios/tabs/host/RNSTabsNavigationState.mm / RNSTabBarController.mm).

Suggested fix

1. In progressNavigationState:withOrigin:, early-return (or keep current state) when newSelectedScreenKey == nil — a Release-mode mirror of the existing assert; UIKit state is reconciled on the next container update.
2. In cloneState / cloneRequest, use [self.selectedScreenKey copy] instead of [NSString stringWithString:...] — equivalent for strings, nil-safe.

We're shipping exactly this as a patch-package patch and it resolves the crash. Happy to open a PR if useful.

Steps to reproduce

1. iOS app using native bottom tabs (we hit it via expo-router unstable-native-tabs) with tab triggers that remount shortly after launch (e.g. a trigger's hidden prop flips after async state rehydration)
2. Release build (so RCTAssert is compiled out), iOS 26 device
3. Cold launch, tap a bottom tab within the first seconds while triggers remount

Snack or a link to a repository

Crash observed in a production TestFlight app (full Apple crash log available on request — incident BA77F785-5D9D-4651-9FB0-BEFE15EFB0B6).

Screens version

4.25.2

React Native version

0.83.4

Platforms

iOS

Device

Real device

Device model

iPhone 15 Pro (iPhone16,1), iOS 26.5

Architecture

Fabric (New Architecture)

[github-actions]

Hey! 👋

The issue doesn't seem to contain a minimal reproduction.

Could you provide a snack or a link to a GitHub repository under your username that reproduces the problem?

[kkafar]

Hey @genchats,

we require the tabs to be defined during the very first render & we don't support intentionally adding / removing tabs dynamically yet.

[...] That is nil while the selected tab's component view is detached — e.g. while tab triggers are being remounted.

I don't understand this. The fact of the component view being detached from view hierarchy is unrelated to it's prop screenKey having the value of nil. It can only be nil in case the screenKey prop is not set, explicitly set to undefined or empty, am I right here?

I acknowledge the problem. Right now I think that the problem lies somewhere else -> in violation of invariant that screenKey is NOT nil. To determine why is that invariant violated we need a reproduction. I understand that this is a timing related problem, however a setup with similar flow that you have in your application (remounting of NativeTabs.Trigger components) is needed. Please provide a repository, where we can experiment.

Suggested fix
In progressNavigationState:withOrigin:, early-return (or keep current state) when newSelectedScreenKey == nil — a Release-mode mirror of the existing assert; UIKit state is reconciled on the next container update.
In cloneState / cloneRequest, use [self.selectedScreenKey copy] instead of [NSString stringWithString:...] — equivalent for strings, nil-safe.

That's a last resort solution. It'll allow for intermediate states being represented on screen, maybe even events with state update send to the JS side, but not reflected in the reference-grade native state. This potentially might introduce even bigger problems.

Way forward: let's focus on preparing a reproduction / playground first, where we can debug this issue and find the actual root cause.