I recently upgraded to Expo SDK 40 and started experiencing extreme glitches with KeyboardAvoidingView. In a couple of cases, the phone became completely unresponsive and had to be hard-restarted. I isolated it to the interaction of React Navigation and react-native-screens. Expo forces [email protected] but explicitly upgrading with yarn add react-native-screens@^2.16.1 doesn't help.
Commenting out these two lines resolves the issue:
import { enableScreens } from 'react-native-screens';
enableScreens();
Only tested/reproduced on iPhone.

The issue doesn't reproduce on Snack seemingly because Snack still uses Expo SDK 39. You can reproduce locally with:
git clone https://github.com/kevgrig/rnkavflickerexpo startimport React from 'react';
import { KeyboardAvoidingView, ScrollView, TextInput } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import { createStackNavigator } from '@react-navigation/stack';
import { enableScreens } from 'react-native-screens';
enableScreens();
const AppStack = createStackNavigator();
function Screen1() {
const [value, onChangeText] = React.useState('');
return (
<ScrollView contentContainerStyle={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
<TextInput
placeholder='Input'
style={{ borderWidth: 1, width: '75%', padding: 10 }}
onChangeText={text => onChangeText(text)}
value={value}
/>
</ScrollView>
);
}
const USE_REACT_NAVIGATION = true;
export default class App extends React.Component {
render() {
return (
<KeyboardAvoidingView behavior='padding' style={{ flex: 1 }}>
{
USE_REACT_NAVIGATION ?
<NavigationContainer>
<AppStack.Navigator>
<AppStack.Screen name='App' component={Screen1} />
</AppStack.Navigator>
</NavigationContainer>
:
<Screen1 />
}
</KeyboardAvoidingView>
);
}
}
Further investigation by an Expo contributor shows that this seems to be related to KeyboardAvoidingView being a parent of NavigationContainer. Moving KeyboardAvoidingView into the screen seems to resolve the issue.
Note for anyone else hitting this that, in testing my more complicated application, moving KeyboardAvoidingView inside of NavigationContainer did not help and commenting out the two enableScreens lines was still the only workaround.
Just wanted to say that we're running into this too. Also since the update from the versions in expo sdk 39 to 40. We're also using react-navigation (but 4.x).
Oh, I just saw that this was likely fixed in 2.16 (https://github.com/software-mansion/react-native-screens/issues/737), and expo sdk 40 is on 2.15. So it seems like it's on expo to upgrade.
(@kevgrig if you use the managed workflow in expo, the package.json upgrade does nothing, since this package uses native code)
@jparkrr Oh, I didn't know that, makes sense. @brentvatne FYI
@kevgrig - thanks for the ping!
Can I close this issue then? Seems that it is resolved (#737), but not available in Expo managed workflow in SDK 40, but we can't do anything about it unfortunately. Can you confirm it @kevgrig?
@WoLewicki I'm using the Expo managed flow so I can't test the (hopeful) solution, so I'd like to wait until the Expo SDK upgrades react-native-screens, but if you'd like to close it, that's okay with me, and I can re-open it if the problem still exists after the next Expo SDK upgrade.
I don't have a strong opinion on it. We can leave it open so people with the same problem can find it easily.
@WoLewicki I have the same problem with the latest version and I'm not using expo: with enableScreens keyboardAvoidingView is flickering on every keyboard tap
@somebody32 could you please provide a repo with the minimal reproduction needed to spot the issue?
@WoLewicki, sorry, my bad, somehow missed that I was not on the last patch version, found that when trying to do a repro in a new repo, updating to the latest version fixed it!
As per Expo issue 11326, the native fix was backported and everything works now. Thanks!
Most helpful comment
Note for anyone else hitting this that, in testing my more complicated application, moving
KeyboardAvoidingViewinside ofNavigationContainerdid not help and commenting out the twoenableScreenslines was still the only workaround.