Sometimes KeyboardAvoidingView does not animate keyboard entering on iOS

[itsramiel]

Describe the bug
I have a case where the KeyboardAvoidingView is no longer animating the entering of the Keyboard on iOS. The setup I had looked like this:

import { useState } from 'react';
import { TextInput, View } from 'react-native';
import {
  KeyboardAvoidingView,
  KeyboardProvider,
} from 'react-native-keyboard-controller';
import Animated, { FadeInRight, FadeOutRight } from 'react-native-reanimated';

function App() {
  const [isFocused, setIsFocused] = useState(false);

  const onFocus = () => {
    setIsFocused(true);
  };

  const onBlur = () => {
    setIsFocused(false);
  };

  return (
    <KeyboardProvider>
      <KeyboardAvoidingView
        behavior="translate-with-padding"
        style={{ flex: 1 }}
      >
        <View style={{ flex: 1, backgroundColor: 'red' }} />
        <View style={{ flexDirection: 'row' }}>
          <TextInput
            style={{
              padding: 12,
              borderWidth: 1,
              borderColor: 'black',
              flex: 1,
            }}
            onFocus={onFocus}
            onBlur={onBlur}
          />
          {isFocused ? (
            <Animated.View
              entering={FadeInRight}
              exiting={FadeOutRight}
              style={{ width: 50, height: 50, backgroundColor: 'green' }}
            />
          ) : null}
        </View>
      </KeyboardAvoidingView>
    </KeyboardProvider>
  );
}

export default App;

Screen Recordings

iOS	Android
Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-08-14.at.06.23.05.mp4	Screen.Recording.2025-08-14.at.6.28.36.AM.mov

The previous example includes animated views with layout animations. I was hoping to reproduce it with simpler config and I was able to do that by using a regular view but setFocus after a timeout:

diff --git a/App.tsx b/App.tsx
index 8e0c6e6..8f0cba2 100644
--- a/App.tsx
+++ b/App.tsx
@@ -4,17 +4,20 @@ import {
   KeyboardAvoidingView,
   KeyboardProvider,
 } from 'react-native-keyboard-controller';
-import Animated, { FadeInRight, FadeOutRight } from 'react-native-reanimated';
 
 function App() {
   const [isFocused, setIsFocused] = useState(false);
 
   const onFocus = () => {
-    setIsFocused(true);
+    setTimeout(() => {
+      setIsFocused(true);
+    }, 0);
   };
 
   const onBlur = () => {
-    setIsFocused(false);
+    setTimeout(() => {
+      setIsFocused(false);
+    }, 0);
   };
 
   return (
@@ -36,11 +39,7 @@ function App() {
             onBlur={onBlur}
           />
           {isFocused ? (
-            <Animated.View
-              entering={FadeInRight}
-              exiting={FadeOutRight}
-              style={{ width: 50, height: 50, backgroundColor: 'green' }}
-            />
+            <View style={{ width: 50, height: 50, backgroundColor: 'green' }} />
           ) : null}
         </View>
       </KeyboardAvoidingView>

Full Example

import { useState } from 'react';
import { TextInput, View } from 'react-native';
import {
  KeyboardAvoidingView,
  KeyboardProvider,
} from 'react-native-keyboard-controller';

function App() {
  const [isFocused, setIsFocused] = useState(false);

  const onFocus = () => {
    setTimeout(() => {
      setIsFocused(true);
    }, 0);
  };

  const onBlur = () => {
    setTimeout(() => {
      setIsFocused(false);
    }, 0);
  };

  return (
    <KeyboardProvider>
      <KeyboardAvoidingView
        behavior="translate-with-padding"
        style={{ flex: 1 }}
      >
        <View style={{ flex: 1, backgroundColor: 'red' }} />
        <View style={{ flexDirection: 'row' }}>
          <TextInput
            style={{
              padding: 12,
              borderWidth: 1,
              borderColor: 'black',
              flex: 1,
            }}
            onFocus={onFocus}
            onBlur={onBlur}
          />
          {isFocused ? (
            <View style={{ width: 50, height: 50, backgroundColor: 'green' }} />
          ) : null}
        </View>
      </KeyboardAvoidingView>
    </KeyboardProvider>
  );
}

export default App;

Screen Recordings

iOS	Android
Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-08-14.at.06.34.30.mp4	Screen.Recording.2025-08-14.at.6.34.36.AM.mov

Repo for reproducing
https://github.com/itsramiel/KeyboardIos

To Reproduce

1. Clone repo
2. Run on iOS
3. tap on input at the bottom
4. Observe how the view is not animated

Expected behavior
I expect the view to animated

Smartphone (please complete the following information):

• Desktop OS: [e.g. Windows 10, MacOS 10.15.5]
• Device: iPhone 16 Pro
• OS: 18.5
• RN version: 0.81.0, 0.80.1(tested on both)
• RN architecture: new
• JS engine: Hermes
• Library version: 1.18.4

Additional context

• ⚠️❗⚠️ Sometimes the first time the keyboard opens it animates but susbsequent ones do not. please make sure to try focusing multiple times
• The issue is with translate-wth-padding. padding seems to work fine

[kirillzyusko]

Hey @itsramiel 👋

Thank you for providing high quality issue ❤️ I'll try to reproduce it on my machine to see what's going wrong here 👀

I think if you use KeyboardStickyView then you will get the same behavior, right?..

[kirillzyusko]

One thing that would fix the problem would be this code:

export const useTranslateAnimation = () => {
  const { reanimated } = useKeyboardContext();

  const padding = useSharedValue(0);
  const translate = useSharedValue(0);

  useLayoutEffect(() => {
    // eslint-disable-next-line react-compiler/react-compiler
    padding.value = reanimated.progress.value;
  }, []);

  useKeyboardHandler(
    {
      onStart: (e) => {
        "worklet";

        if (e.height === 0) {
          padding.value = 0;
        }
-      if (OS === "ios") {
-         translate.value = e.progress;
-      }
      },
      onMove: (e) => {
        "worklet";

-      if (OS === "android") {
          translate.value = e.progress;
-      }
      },

But in this case we kind of discard the native animation driven by OS and drive our own animation. In most cases it should work just fine, but still would be good to understand why exactly animation becomes instant.

I have a suspicion, that it happens because you trigger re-render, react sees that old animation value was 0, new is 291 (keyboard height) and it set new style, but... It does it in the next frame. And this is the problem for iOS, because if you set it one frame later, then iOS understand that this change is not caused by the fact that keyboard did appear, and it doesn't animate this transition.

Of course it's just my assumption and I need to double verify that, but as a temporary workaround you can update shared value on each keyboard move and in this case the animation will be running smooth without skipped frames.

[itsramiel]

@kirillzyusko I am on vacation this week. Will check it out as soon as I am back 🙏

[itsramiel]

I think if you use KeyboardStickyView then you will get the same behavior, right?..

By "you will get the same behavior", you mean that it does not animate? If so, no KeyboardStickyView seems to work fine

One thing that would fix the problem would be this code:

Yes this does seem to fix it

But in this case we kind of discard the native animation driven by OS and drive our own animation. In most cases it should work just fine, but still would be good to understand why exactly animation becomes instant.

I did not know that you are utilising the native animation driven by the OS(out of curiosity only can you link the code that does that in native ios). Were you able to find out what is the best way to fix this, whether to use the suggested fix above or something else?

I have a suspicion, that it happens because you trigger re-render, react sees that old animation value was 0, new is 291 (keyboard height) and it set new style, but... It does it in the next frame. And this is the problem for iOS, because if you set it one frame later, then iOS understand that this change is not caused by the fact that keyboard did appear, and it doesn't animate this transition.

I do also think it is related to the rerender but I don't really understand how you manage translations on iOS. I tried to check out the useTranslateAnimation and was surprised to see that you had conditionally set shared values. I am not following you here very much. I believe it is related to the point above

Any updates?

[itsramiel]

@kirillzyusko do you plan on fixing this in the short term? What's the plan?

[kirillzyusko]

Hey @itsramiel

Sorry for a long response - also was on vacation, then on workation, then on conference so only now finally can get back to the work.

If so, no KeyboardStickyView seems to work fine

Okay, this is super interesting 👀

I did not know that you are utilising the native animation driven by the OS(out of curiosity only can you link the code that does that in native ios).

I think this code is hidden in iOS itself. Basically if you change style and keyboard is about to start its movement, then iOS will automatically animate all views that are changing style before keyboard gets shown. So literally if you change translateY from 0 to 336, then iOS will animate this view together with keyboard movement and you will get a frame-in-frame precision animation. The only one requirement is to do that in first keyboard frame. If you apply it slightly later then animation will be instant, because OS will think it's not keyboard animation so no need to be animated along with the keyboard. I hope I explained it, but if it's still unclear - let me know and I'll try to re-phrase it better 🙃

Were you able to find out what is the best way to fix this, whether to use the suggested fix above or something else?

As a temporary workaround please, use the fix above. Since you mentioned that KeyboardStickyView doesn't have this problem and KeyboardAvoidingView with translate behavior has - I definitely need to investigate that, because both of them uses translateY property (so I suspected they had to work identically).

I do also think it is related to the rerender but I don't really understand how you manage translations on iOS. I tried to check out the useTranslateAnimation and was surprised to see that you had conditionally set shared values. I am not following you here very much. I believe it is related to the point above

Yeah, basically if you change shared value to final destination you'll set a final position (and you'll do it synchronously in one frame) and OS will see this change, will see that keyboard is about to be shown and will automatically animate this transition. When you use onMove handler and update shared value there you kind of opt-out from native animation usage and you can control each frame (in my observations I didn't notice any downsides of this approach, like higher CPU consumption or battery drain, so I think it's totally okay to use it. the only one thing why I don't merge this fix upstream is because I want to dig deeper and see why KeyboardStickyView works without any problems and why KeyboardAvoidingView is "sensitive" to re-renders).

---

So the short answer, you can use provided workaround, but I'd like to allocate some more time to understand why exactly additional render breaks the native driven animation.

[itsramiel]

Perfect, thank you! Will use the workaround for now 👍

[oscar-v0]

Still an issue on expo@54+Fabric. I'm also using the workaround for now. Thanks for the great library. Hope it gets resolved soon

[kirillzyusko]

A quick update: me and @IvanIhnatsiuk ran into the same problem yesterday, but with a different component (KeyboardChatScrollView). We were using the same approach - change props in onStart handler, so that CoreAnimation "sees" that update and automatically animates the content.

I quickly debugged and I think I found a problem. Here is a breakdown:

1. shadowTreeWillCommit: REACT commit          ← setFocused(true) triggers React commit
2. collectProps: contentOffset={"y":862.33}     ← reads OLD value from registry (i. e. it's current scroll position, with avoiding view it's `translateY` property
3. PAUSING Reanimated commits                   ← Reanimated is now BLOCKED
   ─── keyboard event arrives AFTER the React commit ───
4. AnimatedPropsRegistry::update: tag=916       ← mapper puts NEW value in updatesBatch_
5. [KB-DEBUG] onStart: height=308               ← keyboard worklet fires
6. flushUpdates: contentOffset={"y":1152.33}    ← batch → registry (correct value), here we update `translateY` in case of avoiding view
7. performOperations: PAUSED with 1 updates     ← can't commit! Reanimated is blocked
8. SKIPPING COMMIT (×3)                         ← blocked for multiple frames
9. shadowTreeDidMount: UNPAUSED                 ← finally unblocked
10. Triggering delayed requestFlush_            ← correct value applied LATE, i. e. when keyboard is already animating, so changing the value will be updated immediately, because it'll not be picked up by CoreAnimation since animation is already in progress

That being said - when we schedule react commit it may block subsequent reanimated updates and we may miss a precious frame and perform update in NEXT frame which will cause an instant animation.

Workarounds that we found:

1️⃣ SharedValue focus driver

instead of react state we were using useSharedValue and bug disappeared (we anyway changed styles of borderColor for focused vs unfocused input).

2️⃣ Patch reanimated (not safe and not well tested)

I prepared this patch, but I don't know how stable is it and whether it can cause regressions 🤔

react-native-reanimated+4.2.1.patch

3️⃣ Delayed react update

As noticed by @itsramiel if you delay the react update and give a reanimated chance to commit its changes first, then everything works as expected 👀

I hope at least we all know what's causing the issue and we know a root cause 👀 (paper architecture doesn't have this problem, by the way, because there was no such concept as ShadowTree).

---

I'll check with reanimated team what would be a proper way of fixing this issue.

[kirillzyusko]

Opened an issue in reanimated: software-mansion/react-native-reanimated#9111