Floating Keyboard Avoidance UI on iPad: The Honest Fix

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, 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 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 (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 and the Pencil canvas, 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 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.

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.