How can I programmatically check whether a keyboard is present in iOS app?
Master System Design with Codemia
Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.
Introduction
On iOS, you usually do not query the keyboard directly. Instead, you observe keyboard show and hide notifications and keep your own state. This event based approach is reliable, animation friendly, and works well with modern UIKit layouts.
Use Keyboard Notifications as the Source of Truth
UIKit posts notifications when the keyboard frame changes. The most useful ones are keyboard will show, keyboard will hide, and keyboard will change frame. You can subscribe in your view controller and update UI constraints when events arrive.
This gives you a reliable boolean value and synchronized animation.
Detect Presence for a Specific Screen
Sometimes you only care if the keyboard is present while one screen is active. In that case, register observers in viewWillAppear and remove them in viewWillDisappear.
This avoids stale callbacks hitting inactive controllers.
When To Use Frame Change Notification
Hardware keyboards, split keyboards on iPad, and language changes can alter frame size without a full hide cycle. Subscribe to keyboard will change frame when your layout depends on exact height.
If you use a scrolling form, consider adjusting content inset instead of fixed constraints so input fields remain visible regardless of keyboard shape.
Testing Keyboard State in Real Devices
Simulator tests are useful, but keyboard behavior can differ with hardware keyboards, split layouts, and third party keyboards. Validate on at least one real iPhone and one iPad configuration. Trigger focus changes between multiple text fields and confirm your isKeyboardVisible state always matches the visual result.
For automated UI tests, you can assert layout changes after tapping a field by checking expected constraint constants or visible element frames. This protects against regressions when refactoring form screens.
Common Pitfalls
- Reading keyboard state from view hierarchy snapshots: this is fragile and can break across iOS versions.
- Forgetting safe area subtraction: bottom inset can be applied twice on newer devices.
- Not removing observers: duplicate callbacks can cause jittery animations.
- Ignoring frame change notification on iPad: layouts may break with floating keyboards.
- Updating UI outside animation timing from notification payload: transitions look abrupt.
Summary
- Keyboard presence in iOS is best tracked through notifications.
- Maintain your own
isKeyboardVisibleboolean in controller state. - Use payload values for animation duration and curve to match system motion.
- Handle frame changes for robust iPad and hardware keyboard behavior.
- Scope observer lifecycle to visible screens for clean, predictable callbacks.
- Test with hardware keyboard scenarios to ensure your visibility state and layout updates still behave correctly when the onscreen keyboard is absent.

