A deep technical breakdown of how keyboard handling differs between iOS and Android in React Native apps, explaining why iOS uses scheduled animations while Android (especially post-Android 15 with forced edge-to-edge) requires per-frame inset tracking via WindowInsetsAnimationCallback. It explains why the built-in KeyboardAvoidingView works well on iOS but breaks on modern Android, and introduces react-native-keyboard-controller's drop-in replacements (KeyboardAvoidingView, KeyboardAwareScrollView, KeyboardStickyView) that unify both platforms behind a single animated value. Written by the library's maintainer as part one of a two-part series.
Table of contents
How keyboards actually work on iOS and AndroidWhy KeyboardAvoidingView from React Native is great on iOS and bad on Android?When KeyboardAvoidingView is not enough - KeyboardAwareScrollViewThe hidden player - KeyboardStickyViewWrapping upQuestions this post answers
Why does KeyboardAvoidingView break on Android 15?
From Android 15 onward, edge-to-edge is forced by default for apps targeting SDK 35, which means the system no longer automatically resizes the window when the keyboard appears. KeyboardAvoidingView relies on the legacy adjustResize behavior and the keyboardDidShow event fired after animation completes, so it does not know about keyboard insets and lets content sit covered by the keyboard. Track platform shifts like Android 15's forced edge-to-edge on daily.dev before they break your keyboard UI in production.
What is the difference between how iOS and Android animate the keyboard appearing?
iOS posts a scheduled notification with a duration and animation curve before the keyboard moves, letting UIKit interpolate the animation for you without exposing intermediate frames. Android, in the modern edge-to-edge model, fires WindowInsetsAnimationCallback events on every single frame with the current keyboard inset, giving no built-in duration or curve to schedule against. Developers wrestling with cross-platform animation mismatches can follow React Native updates on daily.dev.
When should I use KeyboardStickyView instead of KeyboardAvoidingView in React Native?
Use KeyboardStickyView when you only need a single element, like a footer, chat input bar, or action button, to rise with the keyboard without touching the rest of the layout. It translates just that child by the keyboard height with no flex recompute or padding shuffle, whereas KeyboardAvoidingView resizes the entire container and can trigger unnecessary re-renders. Compare component choices like this on daily.dev when deciding how to structure React Native keyboard UX.