[iOS][New Arch] Fatal crash (std::terminate / EXC_CRASH SIGABRT) in RNSSafeAreaViewComponentView::updateState triggered by iOS Password AutoFill bar

[lucasbriguenti]

Description

On iOS 26.5 (and likely iOS 18.x) with the New Architecture (Fabric), the app crashes with
EXC_CRASH (SIGABRT) / std::terminate() when the user focuses an email or password field
that triggers the iOS Password AutoFill suggestion bar (the QuickType bar with credentials
from the iOS "Passwords" app appearing above the keyboard).

The crash is fatal, happens on Thread 0 (main thread), and is not catchable by JS-level error
boundaries. It is reproducible consistently when using the native iOS AutoFill flow on a login
screen that contains a SafeAreaView from react-native-screens.

Root cause analysis

When the iOS Password AutoFill bar appears above the keyboard, the OS changes windowInsets,
which triggers UIView's safeAreaInsetsDidChange. RNSScreenView intercepts this via
`-[RNSScreenView safeAreaInsetsDidChange]` (RNSScreen.mm:1172) and posts an
RNSSafeAreaDidChange NSNotification. RNSSafeAreaViewComponentView receives this notification
and calls updateState, which uses EventQueue::UpdateMode::unstable_Immediate.

unstable_Immediate causes the state update — and consequently ShadowTree::commit — to run
synchronously on the main thread. If a Fabric layout pass or mounting transaction is already
in progress at that instant (which is the case during the AutoFill bar appearance, as the keyboard
layout change drives simultaneous RCTMountingManager::initiateTransaction), the ShadowNode
being cloned by ConcreteComponentDescriptor::cloneProps is in an intermediate state. This
causes RawPropsParser::preparse (RawPropsParser.cpp:98) to encounter invalid prop types,
throwing a folly::TypeError which propagates as an unhandled C++ exception and terminates the
process via FIRCLSTerminateHandler / _objc_terminate.

The unstable_Immediate flag was introduced for safe area updates as a side effect of PR #3274
(SplitView synchronous updates), and the #if REACT_NATIVE_VERSION_MINOR >= 82 guard was
removed in PR #4062, making it unconditional in main.

Crash stack (Thread 0)

0   libsystem_kernel.dylib        __pthread_kill + 8
1   libsystem_pthread.dylib       pthread_kill + 268
2   libsystem_c.dylib             abort + 160
3   libc++abi.dylib               demangling_terminate_handler() + 272
4   libobjc.A.dylib               _objc_terminate() + 172
5   App                           FIRCLSTerminateHandler() (FIRCLSException.mm:466)
6   libc++abi.dylib               std::terminate() + 108
7   App                           facebook::react::RawPropsParser::preparse(facebook::react::RawProps const&) const (RawPropsParser.cpp:98)
8   App                           facebook::react::ConcreteComponentDescriptor<facebook::react::ViewShadowNode>::cloneProps(...) (ConcreteComponentDescriptor.h:115)
9   App                           facebook::react::ShadowNode::clone(...) (ShadowNode.cpp:148)
10  App                           facebook::react::ShadowNode::cloneTree(...) (ShadowNode.cpp:402)
...
N   App                           facebook::react::ConcreteState<facebook::react::RNSSafeAreaViewState>::updateState(...) (ConcreteState.h:110)
N+1 App                           -[RNSSafeAreaViewComponentView updateState] (RNSSafeAreaViewComponentView.mm:108)
N+2 CoreFoundation                NSNotificationCenter posting
N+3 App                           -[RNSScreenView dispatchSafeAreaDidChangeNotification] (RNSScreen.mm:1162)
N+4 App                           -[RNSScreenView safeAreaInsetsDidChange] (RNSScreen.mm:1172)
N+5 UIKitCore                     -[UIView _safeAreaInsetsDidChangeFromOldInsets:]

Steps to reproduce

1. Create a login screen with a <SafeAreaView> (from react-native-screens) wrapping the layout.
2. Add a text input with keyboardType="email-address" and a secureTextEntry input below it.
3. Run on a real device with iOS 26.5 (also expected on iOS 18.x).
4. Tap the email field.
5. When the iOS Password AutoFill bar (credentials suggestion row from the Passwords app) appears above the keyboard → app crashes immediately.

Environment

react-native-screens	4.25.2
react-native	0.83.2
New Architecture	enabled (Fabric)
iOS	26.5 (also expected on 18.x)
Devices confirmed	iPhone 13 (iPhone14,5), iPhone 12 Pro, iPhone 15
Distribution	TestFlight + production App Store

Workaround

Removing UpdateMode::unstable_Immediate from RNSSafeAreaViewComponentView::updateState
makes the state update async again and eliminates the race condition:

--- a/ios/safe-area/RNSSafeAreaViewComponentView.mm
+++ b/ios/safe-area/RNSSafeAreaViewComponentView.mm
@@ -105,13 +105,7 @@ - (void)updateState
   }

   auto newData = facebook::react::RNSSafeAreaViewState{...};
-  _state->updateState(
-      std::move(newData),
-      facebook::react::EventQueue::UpdateMode::unstable_Immediate
-  );
+  _state->updateState(std::move(newData));
 }

Applied locally via patch-package. The tradeoff is one extra async frame before safe area insets
are applied — visually imperceptible in practice.

Notes

• The crash is not related to react-native-safe-area-context — the failing class is
  RNSSafeAreaViewComponentView from react-native-screens (prefix RNS, not RNC).
• The unstable_Immediate mode is intentional for SplitView (PR feat(iOS, SplitView): SplitView synchronous updates #3274), but applying it to
  all safe area view updates introduces this reentrancy hazard on the main thread during
  keyboard/inset transitions.
• A scoped fix could be to guard the unstable_Immediate mode exclusively for
  RNSSplitScreenComponentView, reverting RNSSafeAreaViewComponentView back to async updates.

[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?

[github-actions]

Hey! 👋

It looks like you've omitted a few important sections from the issue template.

Please complete Snack or a link to a repository, Screens version, React Native version and Platforms sections.

[kkafar]

Hi @lucasbriguenti, thanks for the report.

We'll try to reproduce the problem and come back to you.

The workaround you suggest is rather not an appropriate solution, because the one-frame content jump you mention is visible and jarring.
If the description of the problem is accurate this sounds rather like a fix in RN core is needed.

[kligarski]

Hi, @lucasbriguenti. I tried reproducing the issue. I created this minimal reproduction example:

Reproduction example

import React from 'react';
import { TextInput, View, StyleSheet, Button, Text } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';
import { SafeAreaView } from 'react-native-screens/experimental';

const Stack = createNativeStackNavigator();

// --- Login Screen ---
function LoginScreen({ navigation }: any) {
  return (
    <SafeAreaView style={styles.container} edges={{ top: true, bottom: true }}>
      <View style={styles.form}>
        {/* Email field configured to trigger AutoFill */}
        <TextInput
          style={styles.input}
          placeholder="Email"
          keyboardType="email-address"
          textContentType="username"
          autoComplete="email"
        />

        {/* Password field configured to trigger AutoFill */}
        <TextInput
          style={styles.input}
          placeholder="Password"
          secureTextEntry={true}
          textContentType="password"
          autoComplete="password"
        />

        {/* Submit button to push the new screen */}
        <Button title="Submit" onPress={() => navigation.push('Success')} />
      </View>
    </SafeAreaView>
  );
}

// --- Success Screen ---
function SuccessScreen({ navigation }: any) {
  return (
    <SafeAreaView style={styles.container}>
      <View style={[styles.form, { alignItems: 'center' }]}>
        <Text style={{ marginBottom: 20 }}>
          You have successfully pushed a new screen!
        </Text>

        {/* Go back button */}
        <Button title="Go back" onPress={() => navigation.goBack()} />
      </View>
    </SafeAreaView>
  );
}

// --- App Container ---
export default function App() {
  return (
    <NavigationContainer>
      <Stack.Navigator>
        <Stack.Screen
          name="Login"
          component={LoginScreen}
          options={{ headerShown: false }}
        />
        <Stack.Screen
          name="Success"
          component={SuccessScreen}
          options={{ headerShown: false }}
        />
      </Stack.Navigator>
    </NavigationContainer>
  );
}

// --- Styles ---
const styles = StyleSheet.create({
  container: {
    flex: 1,
    backgroundColor: '#f5f5f5',
  },
  form: {
    flex: 1,
    justifyContent: 'center',
    padding: 20,
    gap: 16,
  },
  input: {
    height: 50,
    backgroundColor: '#ffffff',
    borderWidth: 1,
    borderColor: '#cccccc',
    borderRadius: 8,
    paddingHorizontal: 12,
  },
});

I tried it on a real iPhone 13 device with iOS 26.4.2. I wasn't able to reproduce this issue in our example app with react-native@0.86.0 nor with new clean app with react-native@0.83.9.

ScreenRecording_06-25-2026.11-40-21_1.MP4

To investigate further, we would need a minimal reproduction example. We would also appreciate a video recording of the bug.