# Floating Keyboard Avoidance UI on iPad: The Honest Fix

> By Lawrence Arya, Founder & CEO of VP0. Published 2026-06-07. 6 min read.
> Source: https://vp0.com/blogs/floating-keyboard-avoidance-ui-ipad

Users drag the keyboard precisely so it stops covering things. An app that flinches anyway looks broken.

**TL;DR.** iPad keyboard avoidance breaks because the iPad has four keyboard modes, docked, floating, split, and hardware, and height-based layout math only describes the first. The honest fix is UIKeyboardLayoutGuide with followsUndockedKeyboard, treating the keyboard as a live constraint region: docked gets classic insets, floating usually gets no avoidance at all (track it only when it covers the focused field), hardware reclaims the space. In React Native, raw KeyboardAvoidingView misreads the floating frame, so detect narrow frames and opt out, or use react-native-keyboard-controller's mode-aware values. Scroll-to-reveal beats layout-shove everywhere. A free VP0 design covers the iPad composer and form screens this lives in.

## Why does "avoid the keyboard" break on iPad?

Because the iPad has four keyboards, and three of them refuse to behave like a bottom-docked rectangle. The docked software keyboard works like the iPhone's. The **floating keyboard** is a draggable mini palette the user can park anywhere, covering an arbitrary patch of any screen edge. The **split keyboard** (on devices that support it) breaks into two halves mid-screen. And a **hardware keyboard** shows no keyboard at all, just an optional shortcut bar.

Layout code written for "keyboard height pushes content up" produces nonsense for three of those four:

| Keyboard mode | What occludes the screen | What avoidance should do |
| --- | --- | --- |
| Docked | A full-width bottom slab | Classic inset: shrink or pad the scroll view |
| Floating | A small draggable window, anywhere | Usually nothing; track it only if it covers the focused field |
| Split | Two mid-screen halves | Treat like floating; height math lies |
| Hardware | Nothing (maybe a shortcut bar) | Nothing; reclaim the space |

The most visible bug this produces: a floating keyboard parked in a corner while the layout still jumps 300 points upward, leaving a crater of empty space under content that nothing occludes. Users drag the keyboard precisely to stop it covering things; an app that flinches anyway looks broken.

## What is the right native API?

[UIKeyboardLayoutGuide](https://developer.apple.com/documentation/uikit/uikeyboardlayoutguide), and specifically its `followsUndockedKeyboard` property. The old `keyboardWillShow` notifications hand you a keyboard frame and leave the interpretation to you, which is exactly where floating-keyboard math goes wrong. The layout guide instead behaves as a live region: docked, it sits where the keyboard sits; undocked with `followsUndockedKeyboard = true`, it tracks the floating palette as the user drags it, and its edge constraints activate depending on which screen edge the keyboard nears.

The constraint mindset replaces the height mindset: pin what must stay visible (the focused field, the send bar) relative to the guide and let the system resolve the geometry per mode. SwiftUI's built-in keyboard avoidance handles the docked case automatically and, correctly, mostly ignores the floating one; the discipline there is not adding manual padding driven by keyboard-height publishers, which reintroduces the crater bug the system already avoided.

One rule survives every mode: **prefer scroll-to-reveal over layout-shove**. Keeping the focused field visible inside a scroll view's adjusted insets moves only what is needed; restructuring the whole screen around keyboard geometry moves everything and ages badly the moment the user drags the palette.

## What about React Native on iPad?

The built-in [KeyboardAvoidingView](https://reactnative.dev/docs/keyboardavoidingview) speaks height: its behaviors compute from keyboard frames, which is fine docked and wrong floating, where the reported frame is a small rect in arbitrary position that height-based padding misreads as a bottom slab. Two workable paths:

- **Detect and opt out**: when the keyboard frame's width is meaningfully narrower than the window, treat it as floating and apply no global avoidance, falling back to `scrollToFocusedInput`-style reveal for the focused field only.
- **Use [react-native-keyboard-controller](https://github.com/kirillzyusko/react-native-keyboard-controller)** (3,602 stars, 1,805,596 weekly downloads), which exposes the keyboard as animated values and modes rather than a single height, giving the floating case an actual representation instead of a lie.

Either way, test the four modes deliberately: iPad simulators toggle floating via the keyboard's own grip handle, and Stage Manager widths multiply the cases, since a narrow window plus a docked keyboard behaves like a phone while the same window with a floating keyboard does not. The broader iPad-input craft, where the pointer, the Pencil, and drag interactions all carry their own geometry, runs through [the cross-app drag-and-drop build](/blogs/drag-and-drop-between-apps-ui-swiftui/) and [the Pencil canvas](/blogs/apple-pencil-drawing-canvas-ui-react-native/), and the keyboard is the same lesson in a different input: respond to what the system reports, not to the iPhone-shaped assumption.

## Where do apps still get it wrong?

Three recurring failures. Accessory bars glued to a keyboard that is not there: an input-accessory toolbar positioned by keyboard height floats mid-air when the keyboard floats, so pin accessories to the focused field or the keyboard layout guide, never to a stored height. Hardware-keyboard blindness: a third of iPad text entry happens with no on-screen keyboard, and reserved blank space at the bottom of a chat screen is dead weight; the guide reports the truth, follow it. And rotation amnesia: a floating keyboard survives rotation in a new position, so any cached geometry from before the rotation is stale, which is one more argument for constraints over stored numbers.

A free [VP0](https://vp0.com) design covers the screens where this matters most, chat composers, forms, note editors, in iPad layouts, so an agent generates field-reveal behavior and guide-pinned accessories instead of hardcoding iPhone keyboard math into an iPad app.

The broader iPad layout question, using the full screen like a Mac instead of stretching a phone, is covered in [the desktop-class NavigationSplitView guide](/blogs/ipad-pro-desktop-class-navigation-split-view-swiftui/).

## Key takeaways: keyboard avoidance on iPad

- **Four keyboard modes, one honest API**: UIKeyboardLayoutGuide with followsUndockedKeyboard replaces height math with live constraints.
- **Floating means mostly don't avoid**: track the palette only when it covers the focused field; the crater bug comes from flinching at a keyboard that occludes nothing.
- **Scroll-to-reveal beats layout-shove** in every mode.
- **React Native needs either a floating-detect opt-out or keyboard-controller's mode-aware values**; raw KeyboardAvoidingView misreads the floating frame.
- **Pin accessories to the field or the guide**, never to a remembered height, and retest under Stage Manager widths.

## Frequently asked questions

**How do I handle the floating keyboard in iPad layout?** Use UIKeyboardLayoutGuide with followsUndockedKeyboard enabled and pin critical UI relative to the guide, or in React Native detect the narrow keyboard frame and skip global avoidance, revealing only the focused field. The floating palette usually occludes nothing, so the correct response is usually nothing. A free VP0 design supplies iPad composer and form screens an agent generates this behavior from.

**Why does my layout jump when the iPad keyboard is floating?** Height-based avoidance code reads the floating keyboard's small frame as a bottom slab and pads accordingly, leaving a crater of empty space. Replace stored-height math with the keyboard layout guide on the native side or mode-aware values from react-native-keyboard-controller in RN.

**Does KeyboardAvoidingView work on iPad?** For the docked keyboard, yes. For floating and split modes its height-derived behaviors misfire, so either opt out when the keyboard frame is narrower than the window or use react-native-keyboard-controller, which models keyboard modes instead of a single height.

**What happens with a hardware keyboard attached?** No on-screen keyboard appears, sometimes just a shortcut bar, and the layout should reclaim the space. The keyboard layout guide reports the true (minimal) geometry; reserved blank space at the bottom is the telltale of height-based code.

**How should input accessory bars be positioned on iPad?** Pinned to the focused field or to the keyboard layout guide, never offset by a remembered keyboard height. A floating keyboard leaves height-positioned accessories hovering mid-air, and rotation invalidates any cached geometry.

## Frequently asked questions

### How do I handle the floating keyboard in iPad layouts?

Pin critical UI to UIKeyboardLayoutGuide with followsUndockedKeyboard enabled, or in React Native detect the narrow floating frame and skip global avoidance, revealing only the focused field. The floating palette usually occludes nothing, so the correct response is usually none. A free VP0 design supplies the iPad composer and form screens to generate from.

### Why does my layout jump when the iPad keyboard is floating?

Height-based avoidance reads the floating keyboard's small frame as a full-width bottom slab and pads the layout anyway, leaving empty space under content nothing covers. Replace stored-height math with the keyboard layout guide, or mode-aware values from react-native-keyboard-controller.

### Does KeyboardAvoidingView work on iPad?

For the docked keyboard yes; for floating and split modes its height-derived behaviors misfire. Either opt out when the keyboard frame is meaningfully narrower than the window, or use react-native-keyboard-controller, which models keyboard modes rather than one height value.

### What should the layout do with a hardware keyboard attached?

Reclaim the space: no on-screen keyboard appears beyond an optional shortcut bar, and the keyboard layout guide reports the minimal geometry. Persistent blank space at the bottom of a screen is the signature of height-based assumptions.

### Where should input accessory toolbars be pinned on iPad?

To the focused field or the keyboard layout guide, never offset by a remembered keyboard height. Floating keyboards leave height-positioned accessories hovering mid-air, and a rotation reposition invalidates any cached geometry.

---
*Published on the [VP0 Journal](https://vp0.com/blogs). Free to read, index and cite with attribution.*