ns-keyboard-input
Keyboard input strategy
The keyboard covering an input has two fundamentally different fixes depending on the screen's shape. Pick the plugin from the use case, not the other way around.
1. Decision framework
| Screen shape | Plugin | Why |
|---|---|---|
Form / settings — multiple TextFields inside a ScrollView, user tabs between fields |
@nativescript/iqkeyboardmanager |
Zero-code global fix: shifts the view controller's view so the focused field stays visible, adds prev/next arrows + Done toolbar. iOS-only (Android's adjustResize/adjustPan usually suffices for forms). |
| Chat / composer / docked search — one input pinned to the bottom edge with scrolling content above | @nativescript/input-accessory |
Moves the input bar into the keyboard's inputAccessoryView (iMessage-style dock, interactive swipe-to-dismiss, auto-scroll, auto-growing input). Works on iOS and Android (WindowInsetsAnimationCompat). |
Anti-patterns: IQKeyboardManager on a chat screen shifts the entire page (header scrolls off, tab bar fights the transform) and does nothing on Android; input-accessory on a multi-field form is wrong because the accessory dock is built around exactly one TextView — forms want field-to-field navigation, not a docked composer.
2. Hard rule: a docked composer must own the bottom edge
Do not use input-accessory on a screen that shows a tab bar. When the keyboard hides, the docked accessory sits at the bottom of the screen — directly on top of the tab bar. There is no styling fix; the screen must be presented without the tab bar. In a TabView-shell architecture, route the composer screen at the root level (a sibling of the shell route, pushed over the whole shell), not inside a tab's child routes; returning is a plain back — the shell and all tab outlets are restored from the nav stack.