How can I make a UITextField move up when the keyboard is present - on starting to edit?

UITextField

Keyboard Handling

iOS Development

Swift Programming

UI Adjustments

How can I make a UITextField move up when the keyboard is present - on starting to edit?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Start Practicing Learn More

Introduction

When the keyboard appears on iOS, the real goal is not to literally move the UITextField itself. The goal is to keep the active field visible and editable. In modern UIKit code, the safest solutions are usually a scroll view inset adjustment or a bottom constraint update, not manually shifting the entire root view by a hard-coded amount.

Prefer a Scroll View or Constraint-Based Layout

If your form lives inside a UIScrollView, adjusting the content inset is usually the cleanest solution. The keyboard occupies space at the bottom of the screen, and the scroll view should gain matching bottom inset while editing.

swift

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

That keeps the form scrollable instead of forcing an awkward fixed upward jump.

If You Have a Bottom Constraint, Adjust That Instead

For layouts built with Auto Layout constraints, it is often better to keep a bottom constraint outlet and animate it with the keyboard.

swift

1import UIKit
2
3final class LoginViewController: UIViewController {
4    @IBOutlet private weak var bottomConstraint: NSLayoutConstraint!
5
6    override func viewDidLoad() {
7        super.viewDidLoad()
8
9        NotificationCenter.default.addObserver(
10            self,
11            selector: #selector(keyboardWillChangeFrame(_:)),
12            name: UIResponder.keyboardWillChangeFrameNotification,
13            object: nil
14        )
15    }
16
17    @objc private func keyboardWillChangeFrame(_ notification: Notification) {
18        guard
19            let frame = notification.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect,
20            let duration = notification.userInfo?[UIResponder.keyboardAnimationDurationUserInfoKey] as? Double
21        else {
22            return
23        }
24
25        let keyboardFrame = view.convert(frame, from: nil)
26        bottomConstraint.constant = max(0, view.bounds.maxY - keyboardFrame.minY)
27
28        UIView.animate(withDuration: duration) {
29            self.view.layoutIfNeeded()
30        }
31    }
32}

This approach is usually cleaner than changing view.frame.origin.y directly.

Scroll to the Active Field

If the form contains multiple text fields, remember that adjusting insets alone does not guarantee the active field is visible. Track the active responder and scroll it into view when editing begins.

That is the missing step in many implementations. The keyboard is no longer overlapping the layout, but the current field may still sit below the visible area.

Why Moving the Whole View Is Fragile

The old approach of shifting the whole root view upward by a fixed number of points causes problems:

the value is rarely correct on every device
it breaks more easily on rotation
safe-area handling becomes messy
multiple text fields need different offsets

So the better mental model is not "move the field up," but "make enough visible space for editing."

Common Pitfalls

Moving the root view by a hard-coded amount instead of responding to the real keyboard frame.
Forgetting that the keyboard frame must be converted into the view's coordinate space.
Adjusting the layout but not scrolling the active field into view.
Registering keyboard notifications without removing observers when appropriate.
Handling only keyboard show and ignoring frame changes caused by QuickType, hardware keyboards, or rotation.

Summary

The best solution is usually to adjust a scroll view inset or a bottom constraint.
Use keyboard notifications to react to the actual keyboard frame.
Prefer layout-aware movement over changing the root view's origin manually.
Track the active text field so it can be scrolled into view.
Think in terms of visible editing space, not literal text-field movement.