Introduction

The simplest way to hide the keyboard when a UITableView scrolls is to use the table view's keyboardDismissMode. UIKit already provides this behavior, so you usually do not need custom gesture code or manual responder juggling. The real choice is whether you want the keyboard to disappear immediately on drag or follow the scroll interactively.

Use keyboardDismissMode

UITableView inherits from UIScrollView, which means it supports keyboardDismissMode directly.

1import UIKit
2
3final class FormViewController: UIViewController {
4    @IBOutlet weak var tableView: UITableView!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8        tableView.keyboardDismissMode = .onDrag
9    }
10}

This is usually the entire fix.

The important modes are:

• '.none: scrolling does not dismiss the keyboard'
• '.onDrag: dragging the table dismisses the keyboard'
• '.interactive: the keyboard tracks the drag interactively'

.onDrag Versus .interactive

Use .onDrag when you want a straightforward dismissal as soon as the user scrolls.

Use .interactive when you want the keyboard to move with the user's finger and feel more tied to the scroll gesture.

tableView.keyboardDismissMode = .interactive

This can feel more polished in form-heavy screens, but it is still the same UIKit feature rather than a separate custom implementation.

Manual Dismissal Is Still Possible

If you need explicit control for a special case, you can also end editing manually.

view.endEditing(true)

For example, inside a scroll delegate callback:

func scrollViewWillBeginDragging(_ scrollView: UIScrollView) {
    view.endEditing(true)
}

This works, but it is usually more code than necessary if keyboardDismissMode already matches the behavior you want.

When the Table Contains Text Inputs

This pattern is especially common when text fields or text views live inside table view cells. In those screens, users naturally expect scrolling to dismiss the keyboard so they can see more rows.

That expectation is one reason UIKit's built-in dismissal modes are so useful: they solve the common form-table interaction directly.

Make Sure the Table View Actually Scrolls

If the table view content is too short to scroll, the user may not trigger the behavior simply because no drag scroll interaction occurs. In that case, the keyboard staying visible is not a failure of keyboardDismissMode; it just means the relevant scroll behavior never happened.

If you need dismissal even without meaningful scroll distance, a tap gesture or explicit endEditing(true) may still be useful.

Avoid Overcomplicating It with Gesture Recognizers

Some implementations add tap or pan recognizers to the whole view just to dismiss the keyboard while scrolling. That can interfere with normal table gestures, selection, and other responder-chain behavior.

Start with the built-in property first. Custom gesture logic should be a fallback for uncommon UX requirements, not the default solution.

Consider Overall Form UX

Keyboard dismissal is only one part of the experience. If the screen contains many editable rows, also think about:

• automatic scrolling to the active field
• content inset or keyboard-safe layout handling
• next-field navigation
• whether interactive keyboard dismissal feels natural in your app

The goal is not merely to hide the keyboard. The goal is to make the form easy to use while keeping content visible.

Common Pitfalls

The most common mistake is writing custom scroll or gesture code before trying keyboardDismissMode, even though UIKit already provides the desired behavior.

Another mistake is expecting the keyboard to dismiss on scroll when the table view is not actually scrollable.

Developers also mix manual endEditing(true) calls with interactive dismissal in ways that create awkward or inconsistent behavior.

Summary

• 'UITableView can dismiss the keyboard on scroll through keyboardDismissMode.'
• '.onDrag is the usual simple choice, while .interactive gives a more fluid dismissal effect.'
• Manual view.endEditing(true) is available but often unnecessary for the common case.
• Start with UIKit's built-in behavior before adding custom gesture handling.
• Good keyboard dismissal is part of overall form usability, not an isolated trick.