scrollable={true} + inner <ScrollView> content becomes invisible after tree-wide re-render (e.g. theme switch), requires JS reload

[davidecallegaro]

Summary

When <TrueSheet scrollable={true}> wraps a child <ScrollView>, the ScrollView's content view becomes invisible after any tree-wide React re-render (e.g. theme/appearance change, locale switch) that happens while the sheet is dismissed. On the next present(), the sheet displays normally but the in-flow content inside the ScrollView is missing. Only sibling absolute-positioned views render. A full JS bundle reload restores it.

Visual repro

Step 1: open the sheet (works correctly). Outer View (red bg) + ScrollView (translucent blue overlay = magenta) + hardcoded yellow DEBUG text + real content + sibling absolute-positioned chip/X overlay — all visible.

Step 3 → 4: dismiss sheet, flip theme, re-open. Outer View (red) and ScrollView (blue overlay = magenta) still paint their backgrounds → confirms both containers are full-size and mounted. The absolute-positioned chip ("FITNESS") + X overlay render. But every in-flow child of the ScrollView — including the hardcoded yellow <Text> with hardcoded black background — is gone.

Repro code

function MySheet() {
  const sheetRef = useRef<TrueSheet>(null);
  const { mode } = useTheme(); // any context that propagates to many components

  return (
    <>
      <Button onPress={() => sheetRef.current?.present()} title=\"Open\" />
      <TrueSheet ref={sheetRef} detents={[0.65, 1]} scrollable={true}>
        <View style={{ flex: 1, backgroundColor: 'red' }}>
          <ScrollView style={{ flex: 1, backgroundColor: 'rgba(0,0,255,0.4)' }}>
            <Text style={{ color: 'yellow', fontSize: 32, backgroundColor: 'black' }}>
              HELLO
            </Text>
            <Text>Body content here…</Text>
          </ScrollView>
          <View style={{ position: 'absolute', top: 0, left: 0, right: 0 }}>
            <Text>This overlay text always renders correctly.</Text>
          </View>
        </View>
      </TrueSheet>
    </>
  );
}

Steps:

1. Open the sheet → all content visible (matches screenshot Refactor: Android improvements #1).
2. Dismiss the sheet.
3. Trigger a tree-wide re-render — e.g. flip the app theme from light to dark (or anything that re-renders dozens of components).
4. Open the sheet again → matches screenshot ERROR Invariant Violation: requireNativeComponent: "TrueSheetView" was not found in the UIManager.  #2.

JS reload restores correct behavior immediately.

What I've ruled out

Hypothesis	Result
State is null at render time	No — outer View renders (magenta visible), so the conditional passed
Text color matches background	No — hardcoded yellow text on hardcoded black bg is also invisible
Container collapse to zero height	No — both outer View and ScrollView paint their full backgrounds (visible magenta)
Content off-screen (bad contentOffset)	No — scrolling the empty area reveals nothing
Stale React ScrollView native instance	No — conditionally mounting the entire subtree on a flag (unmount on dismiss, mount fresh on present) does not fix it
TrueSheet's React instance is stale	No — key={mode} on <TrueSheet> to force full React remount of TrueSheet itself also doesn't fix it

The only thing that fixes it short of a JS reload is removing the inner <ScrollView> entirely (rendering content directly into a plain <View>). With that, the same content renders correctly after theme switches every time.

Hypothesis

scrollable={true} appears to install some native-side observation/binding on the inner UIScrollView. After tree-wide re-renders that recreate the inner ScrollView's native view, the binding ends up in a state where the content view stays hidden, even though the JS side reports it mounted. Reload reconstructs the entire native sheet, restoring it.

Note: this app runs on the New Architecture (Fabric). On Fabric, native views can be unmounted/recreated more aggressively during reconciliation than on the old bridge. The bug may be specific to Fabric, or simply easier to trigger there — worth confirming whether old-arch users hit the same symptom.

Workaround

Remove the inner <ScrollView>. Lay content directly into a <View>:

<TrueSheet scrollable={true}>
  <View style={{ flex: 1, padding: 16 }}>
    {/* content */}
  </View>
</TrueSheet>

Trade-off: lose in-sheet scrolling for content that overflows the detent height.

Environment

• @lodev09/react-native-true-sheet: 3.9.9
• react-native: 0.83.6
• react: 19.2.0
• expo: ~55.0.24
• iOS: 16+ deployment target, tested on iOS 17/18
• Architecture: New (Fabric) — newArchEnabled: true in app.config.js
• Device: iPhone (physical + simulator both reproduce)

Happy to help

If a maintainer can point me at the Swift code that handles the scrollable binding, I'd be happy to attempt a PR — the symptom strongly suggests the observation isn't being torn down + re-established when the underlying UIScrollView is recreated.

[github-actions]

Hey @davidecallegaro! Thanks for opening the issue.

It looks like your issue is missing a valid reproduction link.

A minimal reproduction helps us investigate and fix the issue faster. Without one, we may not be able to help.

Please provide one of the following:

• A GitHub repository under your username
• An Expo Snack

See "How to create a Minimal, Reproducible Example" for more guidance.

You can edit your original issue or leave a comment with the repro link. Issues without reproductions may be closed after 14 days.

[davidecallegaro]

[davidecallegaro]

Minimal reproduction repo: https://github.com/davidecallegaro/truesheet-repro-686

To run:

git clone https://github.com/davidecallegaro/truesheet-repro-686
cd truesheet-repro-686
yarn install
npx expo prebuild --platform ios --clean
npx expo run:ios

Then in the app:

1. Tap Open sheet → magenta sheet with yellow DEBUG text + body (working).
2. Swipe to dismiss.
3. Tap Flip mode — flips a context value consumed by 50 dummy components, mimicking the tree-wide re-render a real theme provider triggers.
4. Tap Open sheet again → DEBUG box + body gone, only the absolute-positioned 'OVERLAY' sibling and sheet chrome render.

Reload the JS bundle and content reappears.

Note: the repro is on Expo 54 / RN 0.81 (current default create-expo-app), original report was on Expo 55 / RN 0.83.6. Same TrueSheet version (3.9.9), New Architecture enabled. Let me know if you need it upgraded to match the original env.

[github-actions]

Thank you for providing a repro! We'll take a look at this issue soon.

[lodev09]

Use latest beta version in your repro, see if it's still an issue

[davidecallegaro]

Update on the minimal repro: it does not trigger the bug, even after scaling it up to 400 cells repainting on a real light↔dark theme flip (Expo 54 / RN 0.81, simulator). Whatever triggers it in production requires more environment than a single screen with theme context.

In the production app (Expo 55 / RN 0.83.6, New Arch, physical device) the bug is 100% reliable. Candidate differentiators that exist there but not in the minimal repro:

• freezeOnBlur: true on the parent <Stack> (the screen hosting the TrueSheet freezes when the user navigates to settings to flip theme, then unfreezes on return)
• react-native-reanimated worklets / scroll handlers
• react-native-gesture-handler
• expo-router's native-stack screen lifecycle
• Native iOS glass material components inside the sheet doing trait-collection lookups during repaint

Happy to add any of those to the repro if you suspect one in particular — just point me at it.

Workaround (remove inner <ScrollView>, render content directly into a <View>) is solid and shipped. Stepping back from active digging on my end; ping me if you want me to extend the repro.

[lodev09]

@davidecallegaro there were fixes to the ScrollView from your pinned version so this issue might be a duplicate already, try searching in the issues page.

Are you able to reproduce it using your repro in production build? Or are you referring to your production app? Can you upgrade your app to use the latest?

[davidecallegaro]

Hey @lodev09 — update after testing the upgrade:

Upgraded production app to 3.10.1, tested on physical iPhone (iOS 18, New Arch, RN 0.83.6). Result: the bug still reproduces.

Specifically:

• Sheets render correctly on first open ✅
• Dismiss + flip theme + reopen → inner <ScrollView> content invisible, only the sibling absolute-positioned overlay and sheet chrome render ❌

So 3.10.0's nestedScrollingEnabled rework + scrollableOptions changes don't address this particular failure mode. The workaround (drop the inner <ScrollView>, render content directly into a <View>) is still required.

One incidental finding while doing the upgrade: our codebase had a small patch-package patch on 3.9.9 in TrueSheetViewController.mm that added a cleanupGestureRecognizer call in viewWillDisappear and re-attached in viewDidAppear (for gesture handlers on the inner UIScrollView). On clean 3.10.1 with the patch removed, first-open works fine — so that patch was apparently masking an issue you already fixed upstream. Removed it as part of the upgrade.

Happy to extend the minimal repro if you want me to chase what specifically triggers the theme-switch failure. Suspects in our app vs the minimal repro: expo-router Stack with freezeOnBlur: true, react-native-reanimated worklets, react-native-gesture-handler, and custom native iOS glass material components in the sheet content.

[davidecallegaro]

Update: trigger pinned to Appearance.setColorScheme, not tree-wide re-renders

After deeper instrumentation today I can narrow this further. The bug is not triggered by theme/locale context propagating to many components — it's specifically triggered by calling iOS Appearance.setColorScheme() mid-session.

Concrete evidence

We use Appearance.setColorScheme() so the in-app theme preference cascades into native glass / BlurView (otherwise those follow OS appearance and visually fight the RN theme). Logging every call site:

[INFO] Appearance.setColorScheme(light) reason=INITIAL_HYDRATE   ← fires once at cold start
[INFO] Appearance.setColorScheme(dark)  reason=PREFERENCE_CHANGE  ← fires when user toggles theme

• Cold-launch in any mode → all sheets work indefinitely. The INITIAL_HYDRATE call happens before any TrueSheet exists, so it's not a trigger.
• First PREFERENCE_CHANGE mid-session → every subsequent sheet in that session is broken, in either theme. Switching back light→dark→light does not restore — only a JS reload does.

So it's not "the user is in dark mode" or "many components re-rendered" — it's the iOS appearance override itself, persisting for the lifetime of the JS bundle.

JS-side instrumentation around the broken present

Per-present logging from inside the failing sheet shows the React layer reports nothing wrong:

[SHEET-DBG] present() called  isPresentedRef=false sheetRefExists=true
[SHEET-DBG] SHEET-CONTENT-RENDER themeMode=dark bg=#0E0E10 textPrimary=#FFFFFF   ← fresh tokens
[SHEET-DBG] ScrollView onLayout w=430 h=932 x=0 y=0                              ← full sheet height
[SHEET-DBG] ScrollView onContentSizeChange w=430 h=744                            ← children measured
[SHEET-DBG] onDidPresent

…yet the ScrollView's children are invisible. Only sibling absolute-positioned views render, exactly as before.

Workarounds tried in production, all unsuccessful

Approach	Result
key={mode} on inner content <View> wrapping the ScrollView	No effect — remount lands in the same broken native state
style={{ flex: 1 }} on the ScrollView (it was missing this)	Fixed an unrelated zero-height issue, but content still invisible after the trigger
scrollable={false} on <TrueSheet>	Causes ScrollView to collapse to h=0 (it depends on the native coordinator for sizing) — not a path forward
Drop inner <ScrollView> (the workaround from the original report)	✅ Still the only thing that works

Refined hypothesis

Appearance.setColorScheme() calls into UIKit, which fires traitCollectionDidChange: across the app and triggers UIKit to reload appearance-dependent UI. Our app's UISheetPresentationController host views appear to lose their connection to the RN-managed UIScrollView's content view at that moment. The ScrollView container itself survives (it paints background, lays out, reports valid bounds back to JS) — but its content subview is no longer composited into the sheet's window after the trait change. New Architecture / Fabric likely makes this easier to trigger.

If you want, I can extend my minimal repro to include an explicit Appearance.setColorScheme() toggle (the previous repro flipped a JS context, which apparently isn't the actual trigger) — that should produce a much smaller, more deterministic reproduction.