The worst kind of bug is the one that works on your machine, works in the simulator, works on a real device over the dev server, and then dies the moment it hits a production build. No code changed. Same commit. It just crashes.
That was my last few days. We ship a multi-tenant React Native app built with Expo (one codebase, a handful of pharmacy clients). After upgrading to Expo SDK 53, the iOS build started crashing on launch in TestFlight. Local dev was completely fine. The release build was dead on arrival.
If you've hit this on SDK 53 or later, here's what's going on.
The cause
In SDK 53, the New Architecture is enabled by default. In SDK 52 it was opt-in. So just by upgrading, we silently moved the whole app onto a new rendering and native-module system (Fabric and TurboModules), whether our dependencies were ready for it or not.
That's the trap. The upgrade didn't feel risky. There was no warning prompt. The default just changed underneath us.
Why it crashed in production but not in dev
This is what cost me the most time, so it's worth being clear about.
A native module that isn't New Architecture compatible doesn't always fail loudly in development. Dev builds are forgiving, and you might not even hit the screen that touches the broken module. So everything looks fine.
The release build is stricter and actually exercises the native side properly. So a module that was quietly limping along in dev turns into a hard crash on launch in TestFlight. Same code, different runtime.
The lesson that stuck: "works in dev" and "works in a release build" are two different claims when native code is involved. I'd been treating them as the same.
How I tracked it down
Nothing clever, just a process:
Get the native crash log, not the JS error. A native crash on launch won't give you a friendly red screen. I pulled the crash report from Xcode (Window > Devices & Simulators > View Device Logs) to get the real stack trace.
Find the culprit in the trace. For us it was our animation library,
react-native-reanimated. It wasn't my code. It was a heavily native dependency, and the version we were pinned to hadn't caught up to the New Architecture. In hindsight it was the obvious first suspect, since reanimated is about the most native-heavy thing in a typical app.Run the doctor. This was the tool I didn't know existed:
npx expo-doctor
It checks your packages against React Native Directory and flags anything untested, unmaintained, or incompatible with the New Architecture. That's when it clicked that this was a dependency problem, not a problem with my code.
The fix
There's a fast fix and a proper fix, and you probably want both in that order.
Fast: opt out and ship. If you have users waiting, turn the New Architecture back off in app.json:
{
"expo": {
"ios": { "newArchEnabled": false },
"android": { "newArchEnabled": false }
}
}
Rebuild and you're back on the old architecture your dependencies already supported. This bought me a stable release while I fixed the real thing. One caveat: this is temporary by design. From SDK 55 (React Native 0.82) onward, you can't disable the New Architecture anymore, so opting out buys time, it doesn't solve it.
Proper: get your dependencies ready. Let Expo pick the version that's actually aligned with your SDK instead of guessing one off npm:
npx expo install react-native-reanimated
That alignment was the fix for us. A lot of libraries already have a compatible release out, you're just pinned to an older one. If a library is genuinely unmaintained with no support, swap it for a maintained one. Then re-run expo-doctor until it's clean and test the release build, not just dev.
What I'd tell past me
A default changing is still a breaking change, even when the changelog is calm about it. "New Architecture enabled by default" is one line in the notes and it rewires how your whole app runs. Read the quiet lines as the dangerous ones.
Test the release build before you trust an upgrade. The gap between "runs in dev" and "runs in TestFlight" is exactly where this kind of bug lives. And run expo-doctor before shipping, not after. It would have shown me the bad dependency up front and saved me the whole crash.
None of this was wizardry. A default I didn't notice, a release build I didn't test, and a tool I didn't know to run. Most of the scary native crashes I've hit turned out to be one boring, knowable thing in a frightening costume.
If your TestFlight build just died on launch mid-upgrade, check the New Architecture first.
If you've upgraded to SDK 53 or later, what was the library that broke your build? I'm curious whether most of these trace back to the same handful of native-heavy dependencies, or if it's more spread out than I think.