[iOS] Modal Bug: Invisible layer blocks UI when rapidly opening and closing modals

Description

There are two modals. When closing a first modal while opening a second modal, and then quickly closing the second modal, the second modal's native layer fails to dismiss properly on iOS, leaving an invisible layer that blocks user interaction with the UI.

This issue may be related to #48611

Steps to reproduce

When the first modal is closed while simultaneously opening a second modal
And the second modal is closed shortly after (within ~100ms)
The second modal's native layer remains on screen as an invisible layer
This invisible layer blocks all user interactions with the underlying UI
The app becomes unresponsive to touch events
The application is completely unusable and must be force-killed

React Native Version

0.77.1

Affected Platforms

Runtime - iOS

Output of `npx @react-native-community/cli info`

System:
  OS: macOS 15.3.1
  CPU: (12) x64 Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz
  Memory: 52.50 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.20.6
    path: ~/.nvm/versions/node/v18.20.6/bin/node
  Yarn:
    version: 1.22.22
    path: /usr/local/bin/yarn
  npm:
    version: 10.8.2
    path: ~/.nvm/versions/node/v18.20.6/bin/npm
  Watchman:
    version: 2025.02.17.00
    path: /usr/local/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /Users/leyserkids/.gem/ruby/2.7.7/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2411.12169540
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.26
    path: /usr/bin/javac
  Ruby:
    version: 2.7.7
    path: /Users/leyserkids/.rubies/ruby-2.7.7/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.1
    wanted: 15.0.1
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.77.1
    wanted: 0.77.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

No errors logs

Reproducer

https://github.com/huanguolin/RnModalIosIssue

Screenshots and Videos

An invisible layer top on the UI:

When reproducing this issue, the following console output is observed:

Welcome to React Native DevTools
Debugger integration: iOS Bridgeless (RCTHost)
Running "RnModalIosIssue" with {"rootTag":1,"initialProps":{},"fabric":true}
---> handleShow 0
---> handleDismiss 1
---> handleDismiss 0

Workaround

A workaround for this issue is available in the workaround branch. When using the workaround, the console output shows proper modal opening and closing sequence:

Welcome to React Native DevTools
Debugger integration: iOS Bridgeless (RCTHost)
Running "RnModalIosIssue" with {"rootTag":1,"initialProps":{},"fabric":true}
---> handleShow 0
---> handleDismiss 0
---> handleShow 1
---> handleDismiss 1

workaround code:

import React, { forwardRef, useRef, useImperativeHandle, useState } from 'react';
import { Modal, ModalProps, Platform } from 'react-native';

// MyModal wraps the React Native Modal with the same API
// and implements a fix for iOS issues with multiple modals
const MyModal = forwardRef<any, ModalProps>((props, ref) => {
    const {
        visible,
        onShow,
        onDismiss,
        ...otherProps
    } = props;

    // Forward the ref to access the underlying Modal methods
    const modalRef = useRef<any>(null);
    useImperativeHandle(ref, () => ({
        ...(modalRef.current || {}),
    }));

    // Workaround for iOS modal issues
    const [innerVisible, setInnerVisible] = useState(visible);
    const [alreadyVisible, setAlreadyVisible] = useState(false);

    const handleDismiss = React.useCallback(() => {
        setAlreadyVisible(false);
        if (onDismiss) {
            onDismiss();
        }
    }, [onDismiss]);

    const handleShow = React.useCallback((e: any) => {
        setAlreadyVisible(true);
        if (onShow) {
            onShow(e);
        }
    }, [onShow]);

    React.useEffect(() => {
        // If Modal UI is not yet visible and needs to be shown, set internal state to visible
        if (!alreadyVisible && visible) {
            setInnerVisible(true);
        }
        // If Modal UI is already visible and needs to be hidden, set internal state to not visible
        if (alreadyVisible && !visible) {
            setInnerVisible(false);
        }
    }, [handleDismiss, alreadyVisible, visible]);

    return (
        <Modal
            ref={modalRef}
            visible={Platform.OS === 'ios' ? innerVisible : visible}
            onShow={handleShow}
            onDismiss={handleDismiss}
            {...otherProps}
        />
    );
});

export default MyModal;

#48611

Are you saying that this is the same issue as #48611

#48611

Are you saying that this is the same issue as #48611

Sorry for not making it clear. I think it might be related.

I also encounter this in react-native@0.80.2 new architecture iOS. I don't think this is related to #48611 as this issue happen in new architecture too. For context, I was closing a Native stack screen with presentation = fullScreenModal. While closing, I display a Modal to overlay and prevent any other interaction with the screen, this overlay should be closed shortly after that, but it does not. If we set transparent={false} in this modal, we will see that after the Native stack screen is closed, the screen turns black, equals to the part the second modal's native layer fails to dismiss properly on iOS, leaving an invisible layer that blocks user interaction with the UI.

+1

You could try adding stacked modal support which would make that bug very unlikely to happen, but you would need to patch react-native and maintain that.

In /React/Fabric/Mounting/ComponentViews/Modal/RCTModalHostViewComponentView.mm

 - (instancetype)initWithFrame:(CGRect)frame
@@ -134,6 +133,13 @@ - (void)presentViewController:(UIViewController *)modalViewController
                    completion:(void (^)(void))completion
 {
   UIViewController *controller = [self reactViewController];
+  
+  // workaround to support stacked modals.
+  while (controller.presentedViewController &&
+          !controller.presentedViewController.isBeingDismissed) {
+     controller = controller.presentedViewController;
+   }
+  
   [controller presentViewController:modalViewController animated:animated completion:completion];
 }

I proposed something similar here but from a conversation i had with Ricardo Cipolleschi turns out this will be very hard to merge into RN Core given how Meta uses the Modal on iOS internally.

Also I suggest being on version 0.82+ given that are other improvements to the modal host view on iOS like this one https://github.com/facebook/react-native/pull/48252/files

fix double modal issue: react/react-native#50152

Separate "importing" modal (and more) (#2)

+1

This is still an issue. RN 0.81 Expo 54

I have multiple modal calls, one is called immediately after another is dismissed, so it can't be fixed with the workaround quite as simply.

This is still an issue. RN 0.81 Expo 54

I have multiple modal calls, one is called immediately after another is dismissed, so it can't be fixed with the workaround quite as simply.

I had the same issue; my workaround was to just use one modal and replace its contents. It does make the codebase a bit uglier, but at least it works.

Additional evidence: this failure can also be reproduced with one Modal instance, by reopening it during its animated dismissal. No second modal, native-stack navigation, login, ad SDK calls, or network request is required by the reproducer.

Tested environment

React Native 0.86.3, React 19.2.8, Fabric, Hermes, iOS Release build.
iPhone 15 Pro simulator, iOS 27.0, Xcode 27.0 (27A266a).
Native host built with Expo 57.0.20. This is a minimal replacement JS entry in an existing native host, not a newly generated bare RN app. The host still contains its native modules.
I compared RCTModalHostViewComponentView.mm with the current v0.87.1 source: the relevant presentation/dismissal/recycle implementation is identical (the file diff only removes an unused import). 0.87.1 has not been runtime-tested here.

Single-modal reproducer

Use this as the entry of an iOS app whose root component is named main (or register App under your app's root name). It automatically runs after startup. After the modal disappears, tap Touch count.

import React, {useEffect, useState} from 'react';
import {AppRegistry, Button, Modal, SafeAreaView, Text, View} from 'react-native';

function App() {
  const [visible, setVisible] = useState(false);
  const [presses, setPresses] = useState(0);
  const [events, setEvents] = useState([]);
  const log = message => {
    console.log('[ModalRepro]', message, Date.now());
    setEvents(previous => [...previous, message]);
  };
  const run = () => {
    log('run');
    [[0, true], [600, false], [650, true], [1000, false]].forEach(([ms, value]) =>
      setTimeout(() => {log(`visible=${value} at ${ms}ms`); setVisible(value);}, ms),
    );
  };
  useEffect(() => {const timer = setTimeout(run, 1500); return () => clearTimeout(timer);}, []);
  return <SafeAreaView style={{flex: 1, backgroundColor: 'white'}}>
    <Text style={{fontSize: 25}}>Single Modal race: fade</Text>
    <Button title={`Touch count: ${presses}`} onPress={() => setPresses(p => p + 1)} />
    <Button title="Run sequence" onPress={run} />
    <Text>{`React visible: ${visible}\n${events.join('\n')}`}</Text>
    <Modal transparent presentationStyle="overFullScreen" animationType="fade" visible={visible}
      onShow={() => log('onShow')} onDismiss={() => log('onDismiss')}>
      <View style={{flex: 1, backgroundColor: '#00000033'}}><Text>Loading</Text></View>
    </Modal>
  </SafeAreaView>;
}
AppRegistry.registerComponent('main', () => App);

Observed comparison

Times below are relative to starting the sequence, after the initial 1500ms startup delay:

animationType	visible changes	Result
fade	true@0, false@600, true@650, false@1000 ms	Invisible modal blocks touch; reproduced in 2 independent launches
none	same sequence	Touch count increments
fade	true@0, false@600, true@1300, false@1900 ms	Touch count increments

The failing sequence reports onShow, onDismiss, onDismiss, with no second onShow. Both passing controls report onShow, onDismiss, onShow, onDismiss.

Native evidence collected after the failure

LLDB was attached after the bug had already occurred, so debugger pauses did not cause the reproduction.

Root view controller (appeared)
  + RCTFabricModalHostViewController (appeared)
      presentation controller: _UIOverFullscreenPresentationController
      view frame: entire screen
      view.subviews: []   // empty!

RCTFabricModalHostViewController.isBeingPresented == NO
RCTFabricModalHostViewController.isBeingDismissed == NO
RCTFabricModalHostViewController.delegate -> RCTModalHostViewComponentView

Host component, inspected via valueForKey:
  _isPresented == 0
  _shouldPresent == 0
  _viewController == nil
  superview == nil

Thus this is not just a frozen JS button: UIKit retains a presented empty controller after the Fabric host has detached and cleared its controller reference. In the original app's matching failure, touch-event ancestry ends at an empty UIView with RCTSurfaceTouchHandler -> UITransitionView -> UIWindow; no context-menu container exists. Normal taps reach the actual tab button instead.

Suspected mechanism (not a verified core fix)

In ensurePresentedOnlyIfNeeded, _isPresented becomes NO before the asynchronous dismissal finishes. A subsequent visible=true can enter the presentation path during that dismissal; there is no presenting/dismissing state or completion-generation check in that method. Later dismissal callbacks and JS Modal.onDismiss can detach the content, and prepareForRecycle clears the host's reference. The final native state above demonstrates the resulting ownership/state mismatch, but does not prove every intermediate UIKit transition.

Could this be covered by serializing presentation/dismissal and reconciling the latest requested visibility after completion, with protection against stale callbacks/recycling while presented? Removing fade is a tested workaround here, not a proposed general core fix.

Unlike the nested-controller case discussed in #54858, this reproduction uses a single Modal and the stranded controller has no child presented controller. I am adding the evidence here because the final failure matches this issue; happy to split out the single-modal variant if preferred.

Another case of this on the new architecture (RN 0.83, Expo 55, newArchEnabled: true): an action sheet Modal was set to hide in the same state update that showed a second Modal. On iOS the second one came up empty and ignored taps until it was swiped away. stablyai/orca#25294 has the details.

The app-side workaround was to wait for the first Modal to unmount before showing the second one, rather than toggling both in the same tick: stablyai/orca#25305.

fix(친구): 온보딩 직후 친구찾기 자동 오픈을 화면 전환 뒤로(0→450ms) — 닫은 뒤 친구 화면 버튼 전부 먹통(iOS)

Navigation Menu

Repository navigation

[iOS] Modal Bug: Invisible layer blocks UI when rapidly opening and closing modals #50152

Description

Steps to reproduce

React Native Version

Affected Platforms

Output of `npx @react-native-community/cli info`

Stacktrace or Logs

Reproducer

Screenshots and Videos

Workaround

Tested environment

Single-modal reproducer

Observed comparison

Native evidence collected after the failure

Suspected mechanism (not a verified core fix)

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[iOS] Modal Bug: Invisible layer blocks UI when rapidly opening and closing modals #50152

Description

Description

Steps to reproduce

React Native Version

Affected Platforms

Output of npx @react-native-community/cli info

Stacktrace or Logs

Reproducer

Screenshots and Videos

Workaround

Activity

cortinico commented on Mar 21, 2025

huanguolin commented on Mar 21, 2025

ZaffranLe commented on Sep 4, 2025

samslow commented on Sep 18, 2025

ewfian commented on Oct 15, 2025

AndreiCalazans commented on Dec 12, 2025

Charmix commented on Mar 4, 2026

phazei commented on May 19, 2026

chartungpatmos commented on May 19, 2026

nahooni0511 commented on Sep 18, 2026

Tested environment

Single-modal reproducer

Observed comparison

Native evidence collected after the failure

Suspected mechanism (not a verified core fix)

elight commented on Oct 4, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Output of `npx @react-native-community/cli info`