Keyboard Handling

Keyboard handling encompasses how mobile applications manage virtual keyboard appearance, content adjustment, input focus, and form navigation. iOS and Android handle keyboards differently, requiring design systems to specify keyboard behavior for consistent form experiences across platforms.

What Is Keyboard Handling

Keyboard handling addresses the challenges posed by virtual keyboards covering significant screen area. When keyboards appear, applications must adjust content to keep active inputs visible. Form navigation between fields must work smoothly. Keyboard dismissal must be intuitive.

Platform differences affect keyboard behavior. iOS keyboards push content up or use scroll adjustment. Android keyboards have various behaviors depending on window soft input mode. These differences require platform-specific attention in design systems.

Poor keyboard handling causes frustration. Inputs hidden behind keyboards, inability to navigate between fields, and difficulty dismissing keyboards all harm user experience. Design systems should specify keyboard handling to prevent these issues.

How Keyboard Handling Works

Keyboard appearance triggers content adjustment. Applications detect keyboard presence and adjust layout to keep the focused input visible. iOS provides keyboard notification APIs. Android uses WindowInsets or legacy methods.

Keyboard Handling by Platform:

iOS Keyboard Handling:
- KeyboardNotification provides keyboard frame
- Adjust scroll view content insets
- Or adjust constraint constants
- Input accessory view for toolbar
- UIResponder chain for focus management

NotificationCenter.default.addObserver(
    self,
    selector: #selector(keyboardWillShow),
    name: UIResponder.keyboardWillShowNotification,
    object: nil
)

Android Keyboard Handling:
- windowSoftInputMode in manifest
- Values: adjustResize, adjustPan, adjustNothing
- WindowInsets API for precise control
- Compose: imePadding() modifier

// Manifest
android:windowSoftInputMode="adjustResize"

// Compose
Modifier.imePadding()

Form Navigation Patterns:
- Previous/Next buttons (iOS toolbar)
- Tab/Enter key handling
- Return key action (next, done, send)
- Explicit navigation buttons

Form navigation moves focus between inputs. iOS commonly uses input accessory toolbars with Previous/Next/Done buttons. Android relies more on keyboard return key behavior. Both approaches should work in cross-platform applications.

Keyboard types match input content. Email inputs show email keyboards with @ symbol accessible. Phone inputs show numeric keypads. URL inputs include / and .com keys. Correct keyboard type dramatically improves input efficiency.

Keyboard dismissal allows users to hide keyboards when not needed. Tapping outside input fields commonly dismisses keyboards. Explicit done buttons provide clear dismissal. Scroll gestures may also dismiss keyboards in some contexts.

Key Considerations

• Content adjustment must keep focused input visible
• Form navigation should work via keyboard and toolbar
• Keyboard types must match input content
• Dismissal gestures should be consistent
• Testing requires actual devices with real keyboards
• Accessibility with external keyboards needs consideration

Common Questions

How do design systems specify keyboard content adjustment?

Behavior specification describes expected adjustment. “Keyboard appearance scrolls content to show focused input with 16pt margin above keyboard” provides clear direction.

Implementation guidance covers platform-specific approaches. iOS documentation describes notification handling. Android documentation covers soft input modes and insets.

Component specifications include keyboard context. Form component documentation should specify expected keyboard behavior when that component has focus.

Testing requirements ensure keyboard handling verification. Forms must be tested with keyboard visible, navigating between fields, and dismissing keyboard.

What keyboard types should design systems specify?

Text keyboard (default): General text input with prediction and correction.

Email keyboard: @ symbol accessible, domain suggestions, no autocapitalization.

Phone pad: Numeric keypad for phone numbers, sometimes with + and * symbols.

Number pad: Pure numeric input for codes, quantities.

URL keyboard: / and .com keys accessible, no autocapitalization.

Search keyboard: Search or Go return key for search field submission.

Decimal pad: Numbers with decimal point for currency, measurements.

Design systems should map input purposes to keyboard types in documentation.

How should keyboard dismissal work?

Tap outside dismissal is expected behavior on both platforms. Tapping on non-input content should dismiss the keyboard and deselect the current input.

Scroll to dismiss can work in scrollable contexts. Beginning to scroll might dismiss the keyboard, though this can interfere with content adjustment.

Explicit dismissal provides clear user action. Done buttons in toolbars, return keys configured as Done, or dedicated close buttons give users explicit control.

Never trap users with keyboards. If there is no obvious way to dismiss the keyboard, users become frustrated. Multiple dismissal methods provide flexibility.

Summary

Keyboard handling ensures applications adjust content when keyboards appear, provide smooth form navigation, and allow intuitive keyboard dismissal. iOS and Android handle keyboards differently, requiring platform-specific implementation approaches. Design systems should specify keyboard types for different inputs, content adjustment behavior, navigation patterns, and dismissal expectations to ensure consistent form experiences.