Introduction

There is no single hardcoded height for the iPhone onscreen keyboard that you should rely on in app code. The visible keyboard frame changes with device, orientation, language, predictive text, hardware-keyboard state, and system UI behavior, so the correct approach is to read the keyboard frame at runtime instead of memorizing a number.

Why a Fixed Height Is the Wrong Model

Older tutorials often mention values like 216 points in portrait or 162 points in landscape. Those numbers were useful as rough historical references, but they are not safe layout rules for modern iOS development.

The keyboard can change height because of:

• portrait versus landscape orientation
• QuickType or suggestion bars
• different input methods and languages
• dictation or accessory controls
• split or floating keyboards on some devices
• hardware keyboards, where the onscreen keyboard may not appear at all

So the practical answer is not "the keyboard is X points tall." The practical answer is "ask UIKit for the current frame."

Read the Keyboard Frame from Notifications

A common UIKit pattern is to observe keyboard frame changes and use the reported rectangle.

1import UIKit
2
3final class FormViewController: UIViewController {
4    override func viewDidLoad() {
5        super.viewDidLoad()
6
7        NotificationCenter.default.addObserver(
8            self,
9            selector: #selector(handleKeyboard),
10            name: UIResponder.keyboardWillChangeFrameNotification,
11            object: nil
12        )
13    }
14
15    @objc private func handleKeyboard(_ notification: Notification) {
16        guard
17            let userInfo = notification.userInfo,
18            let keyboardFrame = userInfo[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect
19        else {
20            return
21        }
22
23        let localFrame = view.convert(keyboardFrame, from: nil)
24        print("Keyboard height in this view: \(localFrame.height)")
25    }
26}

This gives you the actual keyboard frame for the current situation instead of a guessed constant.

The Visible Overlap Matters More Than Raw Height

Even the reported keyboard height is not always the value you should directly apply. What you usually need is the amount of overlap between the keyboard and your view.

For example:

let overlap = max(0, view.bounds.maxY - localFrame.minY)

That value tells you how much vertical space the keyboard is actually covering relative to your current view. This is often more useful than the keyboard's raw frame height, especially in nested layouts or presentations.

A Practical Layout Example

Suppose you have a bottom constraint for a text field container. You can update that constraint when the keyboard moves.

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

This keeps the composer above the keyboard regardless of its exact size.

Prefer Modern Layout Tools When Possible

On newer UIKit code, UIKeyboardLayoutGuide can be cleaner than manually observing notifications for every screen. It lets Auto Layout track the keyboard position as part of the layout system.

The important idea stays the same: let UIKit describe the current keyboard geometry instead of guessing it yourself.

Real-World Variation

Even on the same phone model, the visible keyboard can differ depending on context. Predictive text may add height. Certain languages may alter the layout. External keyboards may suppress most of the onscreen keyboard. Modal presentations and safe-area interactions also change how the keyboard overlaps your content.

So if someone asks, "What is the height of the iPhone keyboard?" the honest development answer is: there are historical approximate values, but production code should treat the height as dynamic.

Common Pitfalls

The biggest mistake is hardcoding a keyboard height like 216 and assuming it will remain correct everywhere. That leads to broken layouts as soon as the input mode or device context changes.

Another common issue is reading the keyboard frame without converting it into the coordinate space of the current view. The system gives you a screen-based frame, so using it directly can produce wrong offsets.

Developers also forget that the value they usually want is overlap, not raw height. A keyboard frame can exist while only partially covering the current view.

Finally, do not ignore cases where the onscreen keyboard is absent or reduced because a hardware keyboard is connected. Your layout logic should still behave sensibly.

Summary

• There is no single safe fixed height for the iPhone onscreen keyboard.
• Historical numbers are rough references, not layout rules.
• Use keyboard notifications or UIKeyboardLayoutGuide to get the actual geometry.
• Convert the keyboard frame into your view's coordinate space.
• In most layouts, the useful number is the visible overlap, not the raw keyboard height.