Your generated app has two gesture systems in it, and nobody told you which one is on.

Which gesture system is your app actually using?

Open package.json and look for react-native-gesture-handler. If it is not there, every gesture in the app is running on what React Native ships, and the only files that matter are the ones with Pressable, Touchable or PanResponder in them. If it is there, both systems are available and the per screen answer is whatever that screen imports. A file with GestureDetector in it is using the library. A file with onPress in it is using the built in path. They can sit next to each other in the same app without complaint.

Being in package.json is not the same as being switched on, which is the detail that wastes the most time. Expo's gestures tutorial says that to get gesture interactions to work you render GestureHandlerRootView at the top of the component and replace the root level View with it. Installed library, missing wrapper, dead gestures, no error message. That combination accounts for a large share of the gestures people describe as broken.

The last thing to check is whether the interaction needs a library at all. Taps, holds and scrolling are all covered by what the framework already has, and the Handling Touches page sends swipes and pans that scroll a list straight to ScrollView. A dependency you do not need is still a dependency you have to upgrade. Tick what your screen has to do and see where the documentation points.

What does React Native do on its own, with nothing installed?

More than people expect, and with real numbers attached. Pressable is described as a Core Component wrapper that can detect the various stages of press interactions on its children. The order is documented: onPressIn fires immediately when a touch is engaged, onPressOut when it is released, and onPress after onPressOut. Hold longer than the delayLongPress default of 500 milliseconds and onLongPress fires instead, with onPressOut still arriving when the finger lifts.

Two of those numbers are the reason a cheap looking app feels cheap. Pressable has a HitRect, set with hitSlop, which defines how far from the element a press can still register, because fingers are not precise and people miss. It also has a PressRect, set with pressRetentionOffset, which lets a press stay alive while the finger slides off the control. Its documented default is 30 at the bottom and 20 on the top, left and right, read 17 October 2026. hitSlop publishes no default at all. A button with no hitSlop in a cramped row is a button people will miss, and the fix is a prop rather than a redesign.

Underneath that is the responder lifecycle, and it is worth reading once even if you never write one. onStartShouldSetResponder asks whether a view wants the touch. onResponderGrant is described as the time to highlight and show the user what is happening. onResponderMove and onResponderRelease carry the finger and the lift. onResponderTerminationRequest lets another view ask for the touch, and onResponderTerminate reports that it has gone, possibly taken by the operating system without asking, which the page says happens with control centre and notification centre on iOS. For anything that has to interpret a drag rather than a press, the page points at PanResponder, which it says reconciles several touches into a single gesture and hands you a gestureState carrying dx, dy, vx, vy and the number of active touches.

The page also states two expectations as best practice, and they are the parts a generated screen most often skips. Every action should have feedback, showing the user what is handling their touch and what will happen when they release. And every action should be cancellable, so the user can abort it mid touch by dragging their finger away. If a tap in your app does nothing visible while a request runs, that is not a slow network problem. It is a missing onPressIn.

React Native, Gesture Responder System, page last updated 12 August 2026, read 17 October 2026

Why does a swipe lose a fight with a scroll?

Because only one view can own a finger, and the rules for who gets it are written down. The ShouldSetResponder handlers are called with a bubbling pattern, deepest node first, which means the deepest component wins when several of them say yes. That is a sensible default and it is exactly wrong for a swipeable row, where the thing you want to win is often the parent. The documented answer is the capture handler: a parent that wants to stop a child from becoming the responder on a touch start should implement onStartShouldSetResponderCapture and return true.

This is why swipe to delete and drag to reorder are the two features that most often come back half working from any code generator, human or otherwise. They are not hard to write. They are hard to arbitrate, because the correct behaviour depends on the angle of the finger in the first few milliseconds, and no specification you wrote in plain English contained that. Expect to describe it again after you have used it.

There is one more place the touch can go that has nothing to do with your layout. React Native notes that the touch area never extends past the parent view bounds, and that the z index of sibling views always takes precedence when a touch hits two overlapping views. A transparent view sitting on top of your button, which is invisible in a screenshot and obvious in the code, will eat every tap. When a control looks right and does nothing at all, that is the first thing to look for, well before debugging a crash that is not happening.

The gesture library does not make the arbitration problem go away. It moves it. Instead of views negotiating in your component tree, native recognisers decide, with the determinism Expo's page advertises. That is usually a better place for the decision to live, especially for anything involving two fingers. It is still a decision somebody has to specify.

What actually breaks when a gesture is added later?

The silent failure comes first, and it is the root wrapper. A gesture built with the library and rendered outside GestureHandlerRootView does nothing and says nothing. No warning, no red screen, no log line. People then rewrite the gesture several times before looking at the top of the app, which is where the problem is. Expo documents the wrapper as the first step of adding gestures at all, so treat a dead gesture as a setup question before you treat it as a code question.

The second thing is the shape of the fix. Expo lists react-native-gesture-handler as included in Expo Go and installs it with npx expo install, which makes it feel like an ordinary package. It is not quite: it carries native code, and native code lives in the binary. A change that adds or upgrades it is a new build going to testers, not a JavaScript bundle you can push on top of the app they already have. That boundary is worth understanding before you promise a fix today, and it is the same boundary that decides what over the air updates can and cannot carry.

The third is the half finished state. Because a responder can be taken by the operating system without asking, every gesture that moves something needs an answer to the question of what happens if it ends early. A sheet dragged halfway and abandoned has to settle somewhere. A reorder interrupted by a phone call has to leave the list in a valid order. This is the work that separates an app that feels finished from one that feels like a demo, and it is almost never in the original description of the feature.

Last, gestures are the part of an app that a reviewer touches with their own hands. Nothing in either store's rules is about gesture libraries, but a control that does not respond reads as a broken app to whoever is holding the phone, and that is a judgement made in seconds. Walk every interactive element on a real device before publishing to the App Store, and tap the things you never tap.

Expo, react-native-gesture-handler reference, read 17 October 2026