Skip to content

What I learned upgrading from Expo SDK 55 to 57

Abdul-Qudus Rufai 1 min read

Spent the past week upgrading our React Native app from Expo SDK 55 to 57.

The Expo SDK 57 release announcement on the Expo changelog.
The Expo SDK 57 release notes.

I expected the usual dependency updates and breaking changes, but I ended up learning quite a bit about the codebase and React itself along the way.

One of the biggest things was understanding component identity better. After enabling the React Compiler and running its lint rules, react-hooks/static-components flagged a few components that were declared inside other components. I knew this wasn’t a pattern I should be using, but seeing the actual effect made it click. Because those components were being recreated on every render, React treated them as new component types, causing their subtrees to unmount and remount.

Another interesting one was the Rules of Hooks. I had an API method called useFeeCalculator. It wasn’t a hook at all, just a regular async function, but because it started with use, the tooling treated it like one. Renaming it to calculateFee fixed the warnings.

It was a small thing, but it reinforced something I hadn’t really thought much about before: naming conventions in React aren’t always just conventions. Tooling can attach actual meaning to them.

I skipped SDK 56 after going through its changelog and finding a documented Hermes and react-native-worklets memory regression that was resolved in the React Native version available with SDK 57. So rather than upgrading just because a newer version existed, I spent more time understanding what I was actually upgrading into.

Along the way, I also cleaned up a few things the upgrade surfaced: JSX issues across multiple files, an unused dependency, navigation migration work, and the remaining expo-doctor warning.

The biggest takeaway for me is that framework upgrades can be a really good way to learn more about your own codebase. You start out trying to change a version number, and end up understanding why certain React patterns exist, how the tooling interprets your code, and which assumptions have quietly been sitting in the project for a long time.

Originally shared on LinkedIn.

Read the SurgePay case study