feat(iOS): Handle interactiveContentPopGesture for iOS 26 #3173

kmichalikk · 2025-08-29T10:16:20Z

Description

Resolves https://github.com/software-mansion/react-native-screens-labs/issues/369, might resolve #3161, reverts #3141, #3142

This PR attempts to enable interactiveContentPopGestureRecognizer for iOS 26 to achieve native screen popping behavior. Until 26, the default was to swipe from the edge of the screen. We had the option to do fullscreen switch, which was controlled by a fullScreenSwipeEnabled prop. Since the default behavior has changed, this prop, along with gestureResponseDistance, is being ignored from now on.

New iOS allows for popping multiple screens almost at once, which we still cannot support due to asynchronous nature of stack updates coming from host to JS that would create a "feedback loop" in situation like the following: host pops 1. screen + sends update, pops 2. screen + sends update -> JS acknowledges 1. update + sends updated state -> host gets 2. screen from JS and pushes it again. This PR attempts to block more than 1 pop at once by removing interactions from the whole screen. As a (desired) side effect, this also disables interactions on the screen below the one that is popped until the transition finishes.

Changes

removed RNSPanGestureRecognizer from iOS 26 build and replace it with native interactiveContentPopGestureRecognizer
disabled all interactions when screens are in transition
updated docs

Test code and steps to reproduce

Use Test3173 to test swipe and interactions on bare screens API & compare with any other test that uses react-navigation stack, i.e Test3093. Use Test3093 with additional screenOptions:

{
        animation: 'slide_from_bottom',
        animationMatchesGesture: true,
}

to test custom animations on swipe back.

guides/GUIDE_FOR_LIBRARY_AUTHORS.md

ios/RNSScreen.mm

kligarski · 2025-09-02T08:45:20Z

ios/RNSScreen.mm

+  if (@available(iOS 26, *)) {
+    // Reenable interactions, see viewWillAppear
+    [self findReactRootViewController].view.userInteractionEnabled = true;
+  }


I'm thinking, is it possible that viewWillAppear will run but viewDidAppear will not? Did you check how prevent remove works now?

I tried this on Test2125 which demos preventRemove

When using back button with prevent remove, the calls look like this:

We are covered by SecondScreen going back on top

When using swipe and not dismissing fully:

It's the same

When using swipe and actually dismissing SecondScreen (preventRemove still on):

Which is different ( 🤔 ) but works for our case

and without preventRemove it's like this:

so in every case at least one of the screens goes through the whole process

ios/RNSScreenStack.mm

src/native-stack/types.tsx

ios/RNSScreenStack.mm

…during transition

…ions

guides/GUIDE_FOR_LIBRARY_AUTHORS.md

kligarski

Please also check behavior with stack nested in modal, as it is attached directly to UIWindow instead of react root view (@WoLewicki's suggestion).

… include modals

kligarski · 2025-09-04T05:54:10Z

ios/RNSScreen.mm

+    // Furthermore, a stack put inside a modal will exist in an entirely different hierarchy
+    // To be sure, we block interactions on the whole window
+    // We need to get the window instance from parent view because it is not set until the view has appeared
+    self.parentViewController.view.window.userInteractionEnabled = false;


Please check one more thing - when you have some push screens and opened modal, when you dismiss the modal and quickly click the back button, will it work correctly (I'm not sure if viewWillAppear will be called)?

And another thing - when I tested main (previous solution), this happened:

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-09-04.at.10.44.06.mov

Please check if this solution prevents this but I managed to also reproduce the bug on iOS 18. If this isn't fixed by this PR, let's create a ticket to investigate this.

when you dismiss the modal and quickly click the back button

It actually broke again in situation: stack1_screenA / stack2_screen A / stack2_screen B / stack2_modal C; when quickly dismissing modal and screen, the whole stack was dismissed. I managed to fix that, but it's not pretty. The main challenge was to find a reference to correct window without using sharedApplication.

As for dismissing multiple modals, native UIKit prevents dismissing more than 2 at once, blocking the third one mid swipe. I ended up blocking every consecutive dismissal similar to regular screens.

And another thing - when I tested main (previous solution), this happened:

I didn't notice anything on my PR

kmichalikk · 2025-09-05T09:30:13Z

Paper appears to work, too.

One other thing I found is that when UIWindow has interactions disabled and we still try to input gestures, this log is shown

Unexpected nil window in latent system gesture client update: windowServerHitTestWindow: <UIWindow: 0x101b05640; frame = (0 0; 402 874); autoresize = W+H; gestureRecognizers = <NSArray: 0x600001829800>; layer = <UIWindowLayer: 0x60000171f100>>, touch: <UITouch: 0x10e788d40> type: Direct; phase: Stationary; is pointer: NO; tap count: 1; force: 0.000; window: (null); responder: (null);

I suspect that's because there is nothing above the window to handle the gesture, but I don't know really. There is not that much info online, other that people having this error when app breaks with black screen, which doesn't happen here.

…ansition

kkafar

The general direction of this PR is good, but I'm unsure of the details.

Didn't we agree that there should be a kill switch, that disables the interactiveContentPopGestureRecognizer?

This PR touches following props:

fullScreenSwipeEnabled,
fullScreenSwipeShadowEnabled,
gestureResponseDistance,
gestureEnabled

Can I ask you to provide a extended description of current behaviour of these props on iOS <= 18 & detailed description of their behaviour & interactions on iOS 26+?

kkafar · 2025-09-16T10:50:52Z

ios/RNSScreenStack.mm

        _controller.interactivePopGestureRecognizer.delegate = self;
+#if RNS_IPHONE_OS_VERSION_AVAILABLE(26_0)
+        if (@available(iOS 26, *)) {
+          _controller.interactiveContentPopGestureRecognizer.delegate = self;


I'm kinda unsure about this line. Is the delegate nil before we assign self? Or do we override some behaviour?

The docs explicitly mention to not do anything but set up failure requirements with this little one.

Yes they do, but sadly they don't explain anything and give no alternatives. On native UIKit test app, the gesture doesn't seem to work without having the delegate set to our controller, but that could be my lack of knowledge about the interactions in native UIKit.

Setting the delegate is necessary to hook the gesture into our logic, have it stop on gestureEnabled: false, etc., and it doesn't work here without setting the delegate either.

For regular edge swipe gesture, we have the same call just above this one, and it, too, doesn't work without it.

I also didn't notice any side effects

Okay, I see. Thank you for explanation.

I'll want to revisit this logic one more time before we land it (I'll do it today).

ios/RNSScreenStack.mm

kkafar · 2025-09-16T10:55:02Z

ios/RNSScreenStack.mm

+        _isFullWidthSwipingWithPanGesture = YES;
+        [self cancelTouchesInParent];
+        return YES;


We fallback into legacy logic here, but why don't we use isInGestureResponseDistance? Do we just ignore it? Is it intended?

AFAIK it's intended. On iOS 26, we want the new gesture to work on the whole screen. The old one is kept only for when user sets custom animations, because we can't animate the native one easily. And in this scenario, the old one should behave as close as the new native one, having only the difference in animation, and without any customization that is exclusive for it.

Okay. That makes sense & complies with weekly conclusions. My suggestion would be to put this reasoning as a comment inside the code. When reading the code I found it "weird" to ignore the gestureResponseDistance in that case.

ios/RNSScreenStack.mm

kkafar

While testing I've also noticed a couple of interesting behaviours. I describe them in follow-up comments 👇🏻

kkafar · 2025-09-16T11:09:47Z

Header back button is exchanged "too quickly"

I do not know yet whether this is a native behaviour (UIKit bug) or maybe intended behaviour, however it looks ugly.

Long text	Regular text
header-changes-too-quickly-2.mov	header-changes-too-quickly.mov

kkafar · 2025-09-16T11:13:17Z

White background is visible on fast swipe

white-background-visible-on-fast-swipe.mov

This is most likely because third & further screens on the stack are frozen or detached.

If they're frozen - we might be able to fix it. If they're detached - then it is UIKit who should attach them :/

kmichalikk · 2025-09-17T08:06:24Z

Re: "White background is visible on fast swipe"

This is a native "rubberband" effect, the white color is actually the background color of RCTSurfaceHostingProxyRootView. We can follow up with a way to change it, or - as pointed out - there could be another view inserted which maybe? (needs confirmation) will be probed for the color.

kkafar

I've spent some time researching why do we have to set ourselves as delegates of interactiveContentPopGestureRecognizer for it to work. It boggles me, because we don't do it in new stack implementation and it works out of the box. Hence, simple conclusion - something prevents it from working. Can't tell what yet.

We should consider supporting gesture response distance with the new gesture. There is no reason to not support it, as this should be straightforward. I want you to create ticket for this.

Also, before this PR (using our custom pan gesture recognizer), user could disable full screen swipe, but leave edge-swipe gesture working. This PR eliminates this granularity. Why don't we change fullScreenSwipeEnabled internal type from boolean to 3-valued enum. If we get undefined, we convert it to system-default or something & on iOS < 26 we disable full screen gesture, >= 26 we enable the full screen gesture. This leaves the granularity in hand of the user.

I think we can proceed here, since this PR is needed, but we should do all above in follow-ups.

kkafar · 2025-09-22T22:09:55Z

Okay, I've found out what makes it work w/o setting the delegate explicitly. This method:

- (id<UIViewControllerAnimatedTransitioning>)navigationController:(UINavigationController *)navigationController
                                  animationControllerForOperation:(UINavigationControllerOperation)operation
                                               fromViewController:(UIViewController *)fromVC
                                                 toViewController:(UIViewController *)toVC
{ ... }

In case where it is NOT overwritten, the gestures do work out of the box. If the method is overwritten & we return nil (the default case, haven't tried returning an animator yet; that's something to try tomorrow), the gesture recognizers won't work w/o setting the delegates.

We can't really resign from overwriting this method, as it's only entry point for animation customisation ==> therefore we're forced to overwrite the delegates.

Let me just note, that this is obviously undocumented UIKit behaviour.

JustJoostNL · 2025-09-26T20:09:35Z

It seems like this change breaks horizontal scrollviews. Is there anything we can do to avoid this?

kmichalikk · 2025-09-30T08:59:05Z

Thanks for info, I'll look into it ASAP.

Fixes #3173 (comment) ## Description #3173 introduced a bug that makes interactiveContentPopGesture dismiss a Screen with content ScrollView immediately, instead of actually scrolling the contents. ~From my testing, the native behavior is to prevent dismissing the screen with such ScrollView entirely.~ The screen should prevent dismissing the screen, only allowing it by swiping from the edge. This change aims to match this behavior. During testing, I also found out, that the previous recognizer works unreliably (sometimes it allows for scrolling, sometimes it dismisses the screen). I'll look into that in separate issue. ## Changes Modified `gestureRecognizer:shouldBeRequiredToFailByGestureRecognizer`, added `gestureRecognizer:shouldRequireFailureOfGestureRecognizer` (only in iOS >= 26). ## Before / After | before | after | | --- | --- | | <video src="https://github.com/user-attachments/assets/00b91d0c-d303-4e88-aef5-ec9659ed9121" /> | <video src="https://github.com/user-attachments/assets/f661d12d-4d8a-48ef-897e-d095b5778531" /> |

huextrat · 2025-10-16T08:33:52Z

fullScreenSwipeEnabled should works on iOS 26 / Xcode 26 thanks to this? 🤔

As on my side, full screen swipe do nothing with iOS 26 / Xcode 26 / v4.17.1

kkafar · 2025-10-16T09:09:12Z

Will check this in 1h & get back to you @huextrat

huextrat · 2025-10-16T09:22:29Z

Will check this in 1h & get back to you @huextrat

I have a repro here : https://github.com/huextrat/repro-screens-fullscreen-swipe

When there is a ScrollView, the fullscreen swipe do not work anymore, it was before v4.17.x
This is not related to Xcode 26 and I can reproduce on Xcode 16 also

terrysahaidak · 2025-10-20T14:14:03Z

I can confirm that full screen swipe does not work when you try to swipe inside a vertical scroll view.

kmichalikk force-pushed the @kmichalikk/disable-screen-interaction-on-transition branch from 9a80b45 to 468b1fe Compare September 2, 2025 06:16

kmichalikk marked this pull request as ready for review September 2, 2025 07:05

kmichalikk requested review from kkafar and kligarski September 2, 2025 07:05

kligarski reviewed Sep 2, 2025

View reviewed changes

kmichalikk force-pushed the @kmichalikk/disable-screen-interaction-on-transition branch from 08ccb30 to 267ff70 Compare September 3, 2025 06:01

kmichalikk added 8 commits September 3, 2025 08:05

Reenable interactiveContentPopGesture for iOS 26, block interactions …

36ccaf6

…during transition

Update tests to match PR

321c915

Use interactiveContentPopGesture for everything besides custom animat…

320ef8b

…ions

Fix gestureRecognizerShouldBegin, add notes to docs

3f315f5

add compile guard to interactiveContentPopGestureRecognizer

66240ab

Remove dead code & fix comments

b4d199c

Adjust the behavior of fullScreenSwipeShadowEnabled

a9c68f5

Remove logs, update defines

852ed1f

kmichalikk force-pushed the @kmichalikk/disable-screen-interaction-on-transition branch from 267ff70 to 852ed1f Compare September 3, 2025 06:19

reset native-stack/types

142d2ac

kmichalikk requested a review from kligarski September 3, 2025 06:23

kligarski approved these changes Sep 3, 2025

View reviewed changes

guides/GUIDE_FOR_LIBRARY_AUTHORS.md Outdated Show resolved Hide resolved

kligarski reviewed Sep 3, 2025

View reviewed changes

kmichalikk added 2 commits September 3, 2025 14:42

Disable interactions on the whole window instead of top react view to…

3598d41

… include modals

Reword doc for fullScreenSwipeShadowEnabled

64e0592

kmichalikk requested a review from kligarski September 3, 2025 13:08

kligarski approved these changes Sep 4, 2025

View reviewed changes

Handle disabling interaction in modals

8dd181f

kmichalikk requested a review from kligarski September 5, 2025 09:31

kligarski approved these changes Sep 8, 2025

View reviewed changes

Merge branch 'main' into @kmichalikk/disable-screen-interaction-on-tr…

5f06448

…ansition

kkafar reviewed Sep 16, 2025

View reviewed changes

kmichalikk added 2 commits September 17, 2025 10:29

Rename isCustomAnimation

35f5595

Remove accidentaly commited backgroundColor

053b1f2

kmichalikk requested a review from kkafar September 17, 2025 08:42

kkafar mentioned this pull request Sep 17, 2025

[iOS 26] Enable native full screen swipe back gesture #3221

Closed

Add comment about gestureResponseDistance

84303f8

mozzius mentioned this pull request Sep 19, 2025

iOS 26 bluesky-social/social-app#9047

Draft

kkafar approved these changes Sep 22, 2025

View reviewed changes

kmichalikk merged commit 32050b9 into main Sep 23, 2025
6 checks passed

kmichalikk deleted the @kmichalikk/disable-screen-interaction-on-transition branch September 23, 2025 09:51

mozzius mentioned this pull request Sep 26, 2025

Patch react native screens with back gesture bugfix bluesky-social/social-app#9087

Merged

kmichalikk mentioned this pull request Sep 30, 2025

fix(iOS): Fix content pop with horizontal scroll #3265

Merged

mk-nickyang mentioned this pull request Oct 5, 2025

fullScreenGestureEnabled: true overlaps with Scrollable list during the momentum scroll on iOS 26 + Xcode 26 react-navigation/react-navigation#12760

Open

12 tasks

t0maboro mentioned this pull request Oct 13, 2025

[iOS 26] Back Button disables if headerShown: false or custom header used #3294

Closed

huextrat mentioned this pull request Oct 16, 2025

[v4.17.x] fullScreenGestureEnabled conflict with ScrollView #3302

Open

okwasniewski mentioned this pull request Oct 18, 2025

react-native-bottom-tabs got slower from 4.16.x to 4.17.x #3307

Open

Uh oh!

Uh oh!

feat(iOS): Handle interactiveContentPopGesture for iOS 26 #3173

feat(iOS): Handle interactiveContentPopGesture for iOS 26 #3173

Uh oh!

Conversation

kmichalikk commented Aug 29, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Changes

Test code and steps to reproduce

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kmichalikk Sep 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kligarski left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kligarski Sep 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kmichalikk commented Sep 5, 2025

Uh oh!

kkafar left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kkafar left a comment

Choose a reason for hiding this comment

Uh oh!

kkafar commented Sep 16, 2025

Header back button is exchanged "too quickly"

Uh oh!

kkafar commented Sep 16, 2025

White background is visible on fast swipe

Uh oh!

kmichalikk commented Sep 17, 2025

Uh oh!

kkafar left a comment

Choose a reason for hiding this comment

Uh oh!

kkafar commented Sep 22, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

JustJoostNL commented Sep 26, 2025

Uh oh!

kmichalikk commented Sep 30, 2025

Uh oh!

kmichalikk commented Aug 29, 2025 •

edited

Loading

kmichalikk Sep 3, 2025 •

edited

Loading

kligarski left a comment •

edited

Loading

kligarski Sep 4, 2025 •

edited

Loading

kkafar commented Sep 22, 2025 •

edited

Loading