keyboardShouldPersistTaps in ScrollView

WHAT THIS TESTS This checks practical knowledge of a frequent forms bug where a tap on a button or input inside a scroll view first dismisses the keyboard instead of activating the target.

A GOOD ANSWER COVERS The relevant prop is keyboardShouldPersistTaps on ScrollView and FlatList. It governs what happens to a tap while the soft keyboard is visible. The value never is the default: tapping outside the focused input dismisses the keyboard and the tap is consumed, so the child does not receive it, which is why a button sometimes needs two taps. The value always means taps always pass through to children and the keyboard stays up regardless. The value handled is the practical sweet spot: the keyboard persists if a child handles the tap, such as pressing a button or another input, but is dismissed when tapping empty space, so buttons and links respond on the first tap while tapping the background still closes the keyboard. Note this is distinct from keyboardDismissMode, which controls whether the keyboard dismisses while you scroll, with values like none, on-drag, and interactive.

COMMON WRONG ANSWERS Confusing keyboardShouldPersistTaps with keyboardDismissMode. Believing the default already lets all taps reach inputs. Using always everywhere, which can make it awkward to dismiss the keyboard by tapping the background.

LIKELY FOLLOW-UPS What does keyboardDismissMode do? Why is handled usually best for forms? How does this interact with nested touchables?

ONE CONCRETE EXAMPLE A login form in a ScrollView shows the keyboard when the email field is focused. With the default, tapping the Submit button just dismisses the keyboard and ignores the press, so it takes two taps. Setting keyboardShouldPersistTaps to handled lets the button receive the first tap and submit, while tapping empty space still closes the keyboard.