KeyboardAvoidingView does not work on multiline TextInputs on iOS

[andrea-martinez-dev]

Describe the bug
The KeyboardAvoidingView component does not work on multiline TextInputs on iOS.
It does work on Android.

Code snippet
See repro

Repo for reproducing
Here a repro on snack.
On snack the bug is reproducible too if you launch it in iOS emulator.
https://snack.expo.dev/@andreamartinez/multiline-textinput-ios-bug

To Reproduce
Steps to reproduce the behavior:

1. Create an app and wrap the content in KeyboardAvoidingView
2. Create a multiline TextInput in a ScrollView, with some generous paddingTop to ensure the keyboard would cover it
3. Launch in iOS device
4. Tap on the multiline TextInput
5. See error

Expected behavior
The KeyboardAvoindingView should work with multiline TextInputs like other inputs (or like Android, where the bug is absent.)

Videos
on iOS the bug is present:

ios.mov

on Android the behavior is correct:

android.mp4

Smartphone (please complete the following information):

• Desktop OS: MacOS 26.5
• Device: iPhone 13 mini (physical), iPhone 16 Pro (virtual on snack)
• OS: iOS 26.5
• RN version: 0.85.3
• RN architecture: new
• JS engine: Hermes
• Library version: 1.2.8

[kirillzyusko]

Hey @andrea-martinez-dev

Thank you for opening the issue and sorry for a long answer.

I've tried to explain in https://youtu.be/W_Y0Y18aFV8?t=170 why KeyboardAvoidingView is not good solution for handling large forms. The correct solution is to use KeyboardAwareScrollView which was designed to work with such kind of layout 🤷‍♂️

The difference that you see in your example is most likely because Android has a bigger screen and when view resizes there is enough space so that even a small push can help to make the input to be visible again. I tested expo snack with larger iPhone and it works also good:

So my recommendation here - just use KeyboardAwareScrollView and it should be working in identical way on both platforms 🤞

I'm going to close this issue, but feel free to leave comments if you still think that something is broken/needs to be fixed/or if you have any other questions 🙏

[andrea-martinez-dev]

@kirillzyusko thanks for your answer.

I'm confident the issue isn't related to Android's larger screen size, that's why I included three TextInputs in my example:

1. A default TextInput (works correctly on iOS)
2. A multiline TextInput (fails on iOS) ← the problematic one
3. A numeric TextInput (works correctly on iOS)

If the screen size were the cause, the numeric input would also fail. Since only the multiline input has issues, this pointed me to a specific bug with multiline TextInputs on iOS.

Regarding your suggestion to use KeyboardAwareScrollView: I tested it and it does work, but unfortunately I can't integrate it into my current screen templates. Simply swapping it in would create nested ScrollViews (ScrollViews wrapped inside a KeyboardAwareScrollView), which isn't ideal.

Thanks for your great work.

[kirillzyusko]

@andrea-martinez-dev KeyboardAvoidingView is not really a great tool for handling large forms. I've tried to explain it here as well: https://blog.margelo.com/deep-dive-in-keyboard-handling#when-keyboardavoidingview-is-not-enough-keyboardawarescrollview

Some interactions, such as:

• input switch (from one input to another)
• caret position tracking
• text change events
• focused input layout changes (when multiline input grows)

Are simply not tracked by KeyboardAvoidingView so "bugs" will be anyway when you use it for forms management. The only one solution when you have a scrollable content is to use KeyboardAwareScrollView in these cases 🤷‍♂️

So yes, I hope you can re-work your code and start to use KeyboardAwareScrollView because it's the component that your layout needs (especially when you have multiline input) 😊

[andrea-martinez-dev]

@kirillzyusko thanks a lot for the link, it made things very clear. A rework will be necessary. :)

If I can give a suggestion, the documentation for KeyboardAvoidingView is a bit ambiguous:

Use KeyboardAvoidingView when you need to prevent the keyboard from hiding important UI elements, especially TextInput components. ... It's ideal for general screens like forms or chat interfaces.

Maybe it could be useful inserting a small warning suggesting the use of KeyboardAwareScrollView instead, for unaware people like me :).