Introduction

Detecting keyboard visibility is really about responding to layout changes when text input starts or ends. The exact API depends on platform, but the goal is the same everywhere: know when the keyboard is visible, measure how much space it consumes, and move or pad your UI so the active field stays usable.

Detect Keyboard Changes on iOS

On iOS, UIKit posts notifications when the keyboard is about to appear, change frame, or hide. The common pattern is to observe keyboardWillShowNotification and keyboardWillHideNotification, read the keyboard frame from the notification payload, and update constraints or content insets.

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(keyboardWillShow(_:)),
12            name: UIResponder.keyboardWillShowNotification,
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    @objc private func keyboardWillShow(_ notification: Notification) {
25        guard let frame = notification.userInfo?[UIResponder.keyboardFrameEndUserInfoKey] as? CGRect
26        else { return }
27
28        bottomConstraint.constant = frame.height + 16
29        view.layoutIfNeeded()
30    }
31
32    @objc private func keyboardWillHide(_ notification: Notification) {
33        bottomConstraint.constant = 16
34        view.layoutIfNeeded()
35    }
36
37    deinit {
38        NotificationCenter.default.removeObserver(self)
39    }
40}

If the keyboard can resize while visible, keyboardWillChangeFrameNotification is often a better signal than only listening for show and hide.

Detect Keyboard Changes on Android

On Android, the modern approach is to read input method editor insets instead of guessing from view height changes. Using WindowInsetsCompat gives a direct answer to whether the software keyboard is visible and how much bottom space it occupies.

1import android.os.Bundle
2import androidx.appcompat.app.AppCompatActivity
3import androidx.core.view.ViewCompat
4import androidx.core.view.WindowInsetsCompat
5
6class LoginActivity : AppCompatActivity() {
7    override fun onCreate(savedInstanceState: Bundle?) {
8        super.onCreate(savedInstanceState)
9        setContentView(R.layout.activity_login)
10
11        val root = findViewById<android.view.View>(R.id.root)
12
13        ViewCompat.setOnApplyWindowInsetsListener(root) { view, insets ->
14            val imeVisible = insets.isVisible(WindowInsetsCompat.Type.ime())
15            val imeBottom = insets.getInsets(WindowInsetsCompat.Type.ime()).bottom
16
17            view.setPadding(0, 0, 0, if (imeVisible) imeBottom else 0)
18            insets
19        }
20    }
21}

This is more reliable than older global-layout heuristics because it asks the system directly for the input-method insets instead of trying to infer them indirectly.

React to Space, Not Just Visibility

In real applications, the useful value is usually the keyboard height or bottom inset, not just a true-or-false flag. Devices, orientations, floating keyboards, and split-screen modes can all change how much space the keyboard actually covers.

That is why robust keyboard handling adjusts:

• bottom constraints on fixed forms
• content insets on scroll views
• the focused control position during field navigation

Treat keyboard detection as a layout input, not just an event to log.

Animation and User Experience

A layout jump is often worse than a partially covered field. On iOS, you can read animation timing from the notification and match it. On Android, inset-aware layouts already make the transition more natural because the system drives much of the movement.

The implementation detail differs across platforms, but the design rule is consistent: move only what needs to move, and keep the focused field visible.

Common Pitfalls

• Listening only for show and hide while ignoring keyboard frame changes.
• Guessing keyboard height from screen size instead of using platform APIs.
• Updating layout without considering scroll views, safe areas, or insets.
• Forgetting to remove observers in longer-lived iOS objects.
• Relying on old Android global-layout hacks when insets are available.

Summary

• On iOS, observe keyboard notifications and read the ending frame from the payload.
• On Android, prefer input-method insets over manual height calculations.
• Use the keyboard height or bottom inset to drive layout changes.
• Keep the active input visible instead of shifting the whole screen unnecessarily.
• Good keyboard handling is mostly about layout correctness and smooth transitions.