SafeAreaProvider returns device-only insets for pre-rendered tabs in NativeTabs

[marcospgp]

Context

When using expo-router's NativeTabs (which uses react-native-screens), all tabs are pre-rendered before the tab bar is measured. This causes nested SafeAreaProviders to return device-only insets (~34px) instead of bounded insets (~83px including tab bar).

Related issues:

• NativeTabs pre-rendering causes safe area flash on first tab visit expo/expo#42486
• Nested SafeAreaProvider ignores parent's initialMetrics, causes flash on mount AppAndFlow/react-native-safe-area-context#689

The Problem

1. NativeTabs pre-renders all tabs simultaneously on app load
2. Pre-rendered tab content doesn't appear to be positioned as a child of the tab bar layout in the native view hierarchy
3. When a nested SafeAreaProvider measures, it gets device-only insets (container to screen edge)
4. When user visits the tab, insets jump from 34px to 83px = visible layout flash

Question

Is there a mechanism in react-native-screens (or could there be) to:

1. Ensure pre-rendered screens in a tab navigator are positioned relative to the tab bar from the start?
2. Provide bounded insets for inactive/pre-rendered screens?
3. Defer SafeAreaProvider measurement until the screen is correctly positioned?

Or is this purely an expo-router concern in how they use react-native-screens?

Workaround

We're currently sharing insets via React context across tab screens and caching the largest bottom value (which includes the tab bar). First tab visited still flashes, subsequent tabs use cached correct insets.

Environment

• expo-router: 6.0.21
• react-native-screens: (via expo)
• react-native: 0.81.5
• iOS 18

[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 Description, Steps to reproduce, Snack or a link to a repository, Screens version, React Native version and Platforms sections.

[marcospgp]

Additional Info

Steps to reproduce:

1. Create an expo-router app with NativeTabs and 3+ tabs
2. Add a nested SafeAreaProvider in each tab screen (for bounded inset measurement)
3. Add a component that uses useSafeAreaInsets().bottom for positioning (e.g., a fixed bottom button)
4. Launch the app
5. Navigate to a tab that wasn't the initial tab
6. Observe the bottom-positioned content jumping as insets change from ~34px to ~83px

Versions:

• react-native-screens: 4.10.0 (via expo ~4.10.0)
• react-native: 0.81.5
• expo: 54.0.31
• expo-router: 6.0.21
• Platform: iOS 18

Why no Snack:
This requires expo-router's NativeTabs (expo-router/unstable-native-tabs) which may not work in Snack. The issue is specific to how NativeTabs pre-renders all tabs simultaneously before the tab bar is measured.

Observed values from debug logging:

• Pre-render: all tabs measure insets.bottom = 34 (device safe area only)
• After tab bar mounts: insets.bottom = 83 (device + tab bar height ~49px)
• The 34→83 jump causes visible layout flash

Architecture: New (Fabric)
Build type: Debug (also occurs in Release)
Device: iPhone 16 Pro Simulator

[kkafar]

Hey @marcospgp,

Haven't verified in runtime, but it seems that this could happen.

The problem here is, that the react native views for "prerendered" tabs are not laid out natively before they are to be displayed for the first time. Their layout is based only on what Yoga produced, and the layout engine does not have any information about the tab bar.

Due to how UITabBarController works only a single controller + its root view ("tab") are displayed at a time (attached to view hierarchy), therefore I don't think we can layout these views correctly w/o them being attached to the HostTree.

One possible workaround (haven't tested here) would be to use SafeAreaView component exported currently from react-native-screens/experimental package, however it has very limited API and in general we're not sure yet in what direction we'll go with its API. If it does not help, then I currently do not have any other possible workaround in mind.