Feature Requests

### Current behavior @react-navigation/bottom-tabs v8 native tabs do not expose a way to configure iOS 26 UIScrollEdgeEffect behavior for tab screen content scroll views. This means apps using native bottom tabs cannot opt out of the default bottom scroll-edge fade/glow behind the tab bar, even when the underlying native tabs implementation can support it. ### Related upstream work react-native-screens PR: software-mansion/react-native-screens#4263 That PR adds/completes support for Tabs.Screen iOS scrollEdgeEffects , for example: ```tsx <Tabs.Screen ios={{ scrollEdgeEffects: { bottom: 'hidden' }, }} /> ### Proposed React Navigation API Expose a bottom-tabs screen option that passes through to the native `Tabs.Screen` iOS prop. One possible shape: ```tsx <Tab.Screen name="Home" component={HomeScreen} options={{ tabBarScrollEdgeEffects: { bottom: 'hidden', }, }} /> React Navigation would pass this to react-native-screens native tabs as: ```tsx ios={{ scrollEdgeEffects: tabBarScrollEdgeEffects, }} ``` I'd be happy to open a PR once there's agreement on the preferred option name and API shape. ### Why this is useful On iOS 26, native bottom tabs can render Liquid Glass tab bars. The default scroll-edge effect can create a visible fade behind the bottom bar. Some apps need to disable that effect per screen, especially when their own content already handles the visual treatment behind the tab bar. ### Platforms iOS 26+, native bottom tabs.

The title and header properties for StackNavigationOptions allow for arbitrary strings as the title prop but I wanted to pass a translation key for the title and localise the text within the header component. I generate a union type of translation key strings based on the translations I have and wanted to restrict the title of navigation screens to be this union type. I was able to patch @react-navigation/stack and @react-navigation/elements to satisfying my needs for react-navigation v6 but now I have to repatch react-navigation v7 and also manually edit files in the lib directory, not just the source code, so that typescript accesses the modified types for my application. Here are the source code changes that I would apply for v7: https://github.com/Charles-Johnson/react-navigation/commit/ffa5bddb718122122008220020af4ee2ee10bca3 Is this something that react-navigation could support in the future or is there a better way to handle my use case? Thank you for your considerations.

I'd love to be able to have a list of detents like ["fitToContents", 1] , so that it fits first, but the user can expand the sheet to go full height.

shrink/grow header when scrolling down/up

What if we could get a fallback parameter for goBack() instead of manually checking canGoBack() then handling that in if else statement? Imagine having a syntax like goBack({ fallback: 'Home' })

Latest Material Design includes large titles similar to iOS but headerLargeTitle option doesn't work on Android More info: https://m3.material.io/components/top-app-bar/guidelines

On tablet in portrait mode it should be awesome to have a tab bar at the bottom and a 1/3 pane left with a list container and at the right side of this pane a 2/3 pane with the detail view of the selection of the list item from the 1/3 part. On tablet in landscape mode, the tab bar should be better aligned at the left of the screen, and still having the 1/3 + 2/3 screen pane ratio. Actually, to be more clear it is a master(list) + detail layout.

I would like bottom tab to be hidden until I scroll all the way to the bottom.

Would be good if, instead of having to use presentation to change how a screen is presented, we could use just methods. For example: navigation.push() navigation.showModal() navigation.dismissModal() navigations.dissmissAllModals() It would also be good if we avoid relying on navigators. Sometimes you have to show a screen in different contexts, and having to use navigators forces code duplication. If we had a single Stack where we could register screens and only call the navigation methods wherever needed, it would be way easier to handle complex navigation scenarios.