This seems like a risky change, as it affects the KeyboardingAvoidingView used across the whole app. Can you expand on the test plan please? Would be good to see more testing done, as well as a deeper analysis of the code to explain why you think this change is safe, both on the level of UX and performance (extra rerenders).

Separately – this feels rather like an uninformed guess. Curious if you've considered these approaches instead:

1. Look at the latest version of this component from React Native here. It would be wise to look for differences between our approach at theirs. At some point we forked it... we could also consider investigating why that was done, and reconsidering whether we should start using the React Native version.
2. Investigate how react-native-keyboard-controller's fork works. This package is popular and may have had to deal with a similar issue.

Look at the latest version of this component from React Native here. It would be wise to look for differences between our approach at theirs.

For iOS, they listen for keyboardWillHide and keyboardWillShow events. They handle the hide event in a different way than the show event, but I would need to dig deeper into the code to understand the differences.

At some point we forked it... we could also consider investigating why that was done, and reconsidering whether we should start using the React Native version.

It was forked in https://github.com/CommE2E/comm/commit/0944d4833c3532b6b821f6216a932996fba202ef with an explanation

Fix up KeyboardAvoidingView to work with react-native-keyboard-input

So if we want to consider using the original version we would need to make sure that it works with react-native-keyboard-input.

Investigate how react-native-keyboard-controller's fork works. This package is popular and may have had to deal with a similar issue.

This library is quite complicated. On the JS side, it listens for events about showing and hiding a keyboard and also maintains a reanimated value, keeping the progress. The native side is a lot more complicated and has a lot of logic around handling the native events regarding keyboard behavior. It is probably too complicated to be worth forking.