When going back in a native stack with a gesture on iOS, keyboard animations and the keyboard itself are not in sync

[matthieugicquel]

Describe the bug

Follow-up to this discussion

A video will be clearer to explain the bug:

keyboard-issue.mov

When tapping to go back, everything is fine (second go back in the video)
When using the gesture, this phantom keyboard is displayed (first and third go back in the video)
RNKC animates its StickyView as if the phantom keyboard was not here, but ends up in the wrong position

Repo for reproducing
https://github.com/matthieugicquel/rnkc-repro-stack

To Reproduce

1. Open the keyboard by focusing the text input
2. Tap "add screen to stack"
3. Go back using a swipe gesture (slowly if you want to see what happens)
4. See keyboard already there, and sticky view moving up

Expected behavior
Ideally: have all APIs (KeyboardStickyView, and I guess other included views and hooks) take this phantom keyboard into account and not report the keyboard opening/closing when in the context of the screen in question.

Smartphone

• Device: iPhone 16 Pro
• OS: iOS 26 (reproduced on 18 too)
• RN version: See repro repo
• RN architecture: Fabric
• JS engine: Hermes
• Library version: 1.18.4

[kirillzyusko]

First of all, as I said, there could be only one instance of the keyboard on the screen:

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-08-13.at.12.14.19.mov

But keyboard instance can be ssociated with a particular screen/view-controller. Currently investigating these "ghost" animations 👀

[kirillzyusko]

A potential workaround is to add "freeze" prop to KeyboardStickyView:

import React, { forwardRef, useEffect, useMemo } from "react";
import { Animated } from "react-native";

import { useKeyboardAnimation } from "../../hooks";

import type { View, ViewProps } from "react-native";
import { useSharedValue } from "react-native-reanimated";
import { useKeyboardHandler } from "react-native-keyboard-controller";

export type KeyboardStickyViewProps = {
  /**
   * Specify additional offset to the view for given keyboard state.
   */
  offset?: {
    /**
     * Adds additional `translateY` when keyboard is close. By default `0`.
     */
    closed?: number;
    /**
     * Adds additional `translateY` when keyboard is open. By default `0`.
     */
    opened?: number;
  };

  /** Controls whether this `KeyboardStickyView` instance should take effect. Default is `true`. */
  enabled?: boolean;
  /** Controls whether to freeze current position. */
  freeze?: boolean;
} & ViewProps;

/**
 * A View component that sticks to the keyboard and moves with it when it appears or disappears.
 * The view can be configured with custom offsets for both closed and open keyboard states.
 *
 * @returns An animated View component that sticks to the keyboard.
 * @see {@link https://kirillzyusko.github.io/react-native-keyboard-controller/docs/api/components/keyboard-sticky-view|Documentation} page for more details.
 * @example
 * ```tsx
 * <KeyboardStickyView offset={{ closed: 0, opened: 20 }}>
 *   <Button title="Submit" />
 * </KeyboardStickyView>
 * ```
 */
const KeyboardStickyView = forwardRef<
  View,
  React.PropsWithChildren<KeyboardStickyViewProps>
>(
  (
    {
      children,
      offset: { closed = 0, opened = 0 } = {},
      style,
      enabled = true,
      freeze,
      ...props
    },
    ref,
  ) => {
    const current = useSharedValue(0)
    const keyboard = useSharedValue(0);

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

        current.value = e.height;
      },
    }, []);

    const { height, progress } = useKeyboardAnimation();

    const offset = progress.interpolate({
      inputRange: [0, 1],
      outputRange: [closed, opened],
    });

    const styles = useMemo(
      () => [
        {
          transform: [
            { translateY: freeze ? keyboard.value : enabled ? Animated.add(height, offset) : closed },
          ],
        },
        style,
      ],
      [closed, enabled, height, offset, style],
    );

    useEffect(() => {
      if (freeze) {
        keyboard.value = current.value;
      }
    }, [freeze]);

    return (
      <Animated.View ref={ref} style={styles} {...props}>
        {children}
      </Animated.View>
    );
  },
);

export default KeyboardStickyView;

Then code can look like this:

export default function Page() {
  const navigation = useNavigation();
  const isFocused = useIsFocused();

  return (
    <View style={styles.container}>
      <AnimatedThing />
      <Button
        title="add screen to stack"
        onPress={() => {
          // setFreeze(true);
          navigation.navigate("page2");
        }}
      />
      <View style={styles.flex} />
      {/* since keyboard is associated with current screen we can "freeze" sticky view position when screen is invisible */}
      <KeyboardStickyView freeze={!isFocused} style={styles.stickyView}>
        <Text>KeyboardStickyView</Text>
        <TextInput
          style={styles.textInput}
          placeholder="Text input with or without autoFocus"
        />
      </KeyboardStickyView>
    </View>
  );
}

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-08-13.at.12.28.49.mov

Simulator.Screen.Recording.-.iPhone.16.Pro.-.2025-08-13.at.12.29.28.mov

@matthieugicquel what do you think about this workaround? I'll also try to investigate why KeyboardStickyView is moving at all too! It's just my first idea and I've seen other use cases for such prop, so thought to share as a possible solution 👀

[matthieugicquel]

For the practical case where I saw this bug, I think my "fix" is going to be switching the screen to a "modal" presentation since I have other good reasons to make this switch anyway.

({ screenOptions: { presentation: "modal" }} in the repro shows that this "phantom keyboard" seems specific to non-modal screens.)

So I'll answer "in theory": the freeze prop might help, but I have some doubts about it:

First, I don't like very much the approach of having to setFreeze() manually before navigating, but it seems the "correct" freeze condition that works all the time would be super-complicated:

Platform.OS === "iOS" &&
!isFocused &&
<reason why not focused> === "screen added to stack with non modal presentation (or something of this kind...)"

Second, the issue isn't specific to KeyboardStickyView. In the concrete case I had, I was using KeyboardStickyView and useKeyboardHandler, but I can imagine cases with every component/API of the lib.

Of courses, with many of the hooks/components, it's already possible to do the freezing manually.

I guess a perfect solution would include the right "freeze condition" defined inside the lib and a screen-level context that applies the freezing to all the APIs.

In the end, I'm not sure it's worth the complexity, maybe a mention of the edge case in the docs or something is enough?

[kirillzyusko]

@matthieugicquel thanks! Everything that you say totally makes sense! I tested how native apps work and it seems they suffer from the same problem:

ScreenRecording_08-28-2025.12-54-15_1.MP4

It's not identical problem, but you can see that symptoms are similar - sticky views are moving during interactive screen dismissal/back swipe while keyboard is locked to its navigation container/screen.

I'll investigate this issue more precisely. It looks like all these sticky views thinks that keyboard actually moves and they try to follow its movement, but in reality keyboard stays unchanged 🤷‍♂️