Introduction

When the iPhone keyboard covers a UITextField, the fix is usually not a custom keyboard overlay. The real problem is that the screen is not adjusting its layout when the keyboard appears. In UIKit, the standard solution is to observe keyboard changes and move or inset the content so the active text field stays visible.

Use a scroll view when the screen contains form fields

If your screen contains several text fields, the most reliable setup is to place them inside a UIScrollView or UITableView. Then, when the keyboard appears, adjust the bottom inset so the content can scroll above it.

1import UIKit
2
3final class FormViewController: UIViewController {
4    @IBOutlet private weak var scrollView: UIScrollView!
5    private weak var activeField: UITextField?
6
7    override func viewDidLoad() {
8        super.viewDidLoad()
9        NotificationCenter.default.addObserver(
10            self,
11            selector: #selector(keyboardWillChangeFrame),
12            name: UIResponder.keyboardWillChangeFrameNotification,
13            object: nil
14        )
15    }
16
17    deinit {
18        NotificationCenter.default.removeObserver(self)
19    }
20
21    @objc private func keyboardWillChangeFrame(_ notification: Notification) {
22        guard
23            let userInfo = notification.userInfo,
24            let frameValue = userInfo[UIResponder.keyboardFrameEndUserInfoKey] as? NSValue
25        else { return }
26
27        let keyboardFrame = view.convert(frameValue.cgRectValue, from: nil)
28        let overlap = max(0, view.bounds.maxY - keyboardFrame.minY)
29
30        scrollView.contentInset.bottom = overlap
31        scrollView.verticalScrollIndicatorInsets.bottom = overlap
32
33        if let activeField = activeField {
34            scrollView.scrollRectToVisible(activeField.convert(activeField.bounds, to: scrollView), animated: true)
35        }
36    }
37}

That handles the common case cleanly and scales well as the form grows.

Track which text field is active

To scroll the right field into view, track editing begin events:

1extension FormViewController: UITextFieldDelegate {
2    func textFieldDidBeginEditing(_ textField: UITextField) {
3        activeField = textField
4    }
5
6    func textFieldDidEndEditing(_ textField: UITextField) {
7        if activeField === textField {
8            activeField = nil
9        }
10    }
11}

Without this, the screen may adjust for the keyboard but still not reveal the exact field the user is trying to edit.

A single text field can be moved, but that does not scale well

If the screen has only one text field, some apps move the whole view upward when the keyboard appears. That works for simple screens, but it is easy to get wrong across different device sizes, safe areas, and rotations.

A scroll-based approach is usually more robust because it works for one field and many fields with the same mental model.

Prefer layout-aware solutions over hard-coded offsets

The wrong fix is usually something like "move the view up by 216 points." Keyboard height varies by device, orientation, hardware keyboard state, and accessory views.

That is why the notification-based approach reads the actual keyboard frame from keyboardFrameEndUserInfoKey instead of guessing.

On newer UIKit setups, keyboardLayoutGuide can also help align content to the keyboard without manually hard-coding offsets. But even then, the underlying idea is the same: respond to the real keyboard frame, not a magic number.

Dismiss the keyboard intentionally

A good keyboard-handling screen also needs a clean dismissal path. A common pattern is to dismiss when the return key is pressed:

1extension FormViewController {
2    func textFieldShouldReturn(_ textField: UITextField) -> Bool {
3        textField.resignFirstResponder()
4        return true
5    }
6}

That does not solve overlap by itself, but it improves the overall form experience once the layout adjustments are in place.

Common Pitfalls

The most common mistake is trying to move views by a fixed keyboard height. That breaks across devices and keyboard configurations.

Another common issue is adjusting the view visually but not tracking the active text field, so the wrong part of the form stays visible.

People also try to solve a scrolling form with manual frame manipulation when a UIScrollView or UITableView would have made the behavior much simpler.

Finally, if you listen for keyboard notifications, remember to remove observers when appropriate and keep the inset logic tied to the actual keyboard frame.

Summary

• The usual fix is to move or inset content when the keyboard appears, not to build a custom keyboard cover.
• For forms, put fields inside a scroll view and adjust the bottom inset.
• Track the active text field so it can be scrolled into view.
• Use the real keyboard frame from notifications instead of hard-coded offsets.
• Prefer scalable layout handling over one-off manual view shifts.