Bottom accessory content view opacity glitch: invalidateLayer resets visibility

[fedeciancaglini]

Description

The bottom accessory content view visibility switching (for RN >= 0.82, dual-content-view approach) can glitch, showing the wrong content view (e.g., the inline copy when the tab bar is in regular/expanded state). This makes UI elements that are conditionally rendered per-placement inaccessible.

RCTViewComponentView.invalidateLayer unconditionally resets self.layer.opacity to the React props value (typically 1.0). This overwrites the 0.0 opacity that RNSTabsBottomAccessoryHelper sets to hide the inactive content view.

The existing mitigations call handleContentViewVisibilityForEnvironmentIfNeeded after:

1. finalizeUpdates: (original fix)
2. traitCollectionDidChange: (fix in fix(iOS, Tabs): bottom accessory opacity on appearance change #3467)

However, invalidateLayer can be triggered from other code paths not covered by these two (mount/unmount cycles of the accessory, prop changes on parent views, animated transitions). When this happens, opacity is reset to 1.0 on both content views, leaving both copies visible simultaneously.

Proposed fix: Override invalidateLayer directly on RNSTabsBottomAccessoryContentComponentView:

- (void)invalidateLayer
{
  [super invalidateLayer];
  [_accessoryView.helper handleContentViewVisibilityForEnvironmentIfNeeded];
}

Steps to reproduce

1. Use NativeTabs.BottomAccessory with different content for regular vs inline placement (e.g., extra buttons only in regular mode)
2. Set minimizeBehavior="onScrollDown" on NativeTabs
3. Scroll down on a tab with native scroll to collapse the tab bar (accessory goes inline)
4. Switch to a tab where the scroll view does not reach the native tab bar (tab bar expands back)
5. The inline content view persists while the tab bar is in expanded/regular state

The glitch is intermittent and more likely when the accessory mount coincides with other prop changes on NativeTabs.

Snack or a link to a repository

We do not have a minimal reproduction repo yet. The issue occurs in a production app with NativeTabs bottom accessory. The root cause is clear from reading the native source: RCTViewComponentView.invalidateLayer resets layer.opacity and only two of many possible call sites are mitigated.

Screens version

4.24.0

React Native version

0.83.2

Platforms

• iOS

JavaScript runtime

Hermes

Workflow

Expo managed workflow

Architecture

Fabric (New Architecture)

Build type

Debug mode

Device

Real device

Device model

iPhone 16 Pro (iOS 26.0 beta)

Acknowledgements

Yes

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

[kligarski]

Hi, @fedeciancaglini. Thank you for reporting the issue.

If (void)invalidateLayer was a publicly defined method in RCTViewComponentView.h, we would use it for sure but as this is defined only in @implementation, we don't really want to rely on internal react-native implementation (even though this isn't the strongest argument as by overriding methods where invalidateLayer is called we already kind of rely on internal implementation).

I searched react-native repository and invalidateLayer seems to be called only in the two places covered by the current solution. Would you be able to provide any information when/how is invalidateLayer called (e.g. stacktrace when invalidateLayer is called that is not covered by our current solution) or a minimal reproduction example?

also, cc @kkafar - what do you think here?

[kkafar]

I think that our current solution is not very robust.

I do wonder now, why haven't we just set a KVO for the opacity?

[kligarski]

I think that our current solution is not very robust.

I do wonder now, why haven't we just set a KVO for the opacity?

I don't recall any reason for why we haven't done it, I guess that we will need to prevent infinite update loop but that should be doable. I'll update the existing ticket: https://github.com/software-mansion/react-native-screens-labs/issues/558 to check KVO approach.

[andveloper]

Possibly related: Full-screen modal dismissal also causes bottom accessory glitches

Simulator.Screen.Recording.-.iPhone.17.Pro.-.2026-04-02.at.23.27.28.mov