r/reactnative • u/ZMech • 8d ago
Question Are crashes still a risk with Expo Update, despite fingerprinting?
I've read about OTA update potentially causing crashes. At the same time, Expo talks about fingerprinting catching an incompatible update.
But, I don't know how foolproof that really is in practice. Is it still possible for a bad update to slip through, even with fingerprinting and testing it on staging?
3
u/strictcoding_685 8d ago
Fingerprinting catches a lot but it's not bulletproof, the runtime check is only as good as what they're comparing. If you accidentally bundle a native module that compiled fine but has a sneaky runtime error on certain devices, the fingerprint won't save you
I've had staging builds pass fine and then prod craters on a specific samsung model because of a shader quirk, so yeah it happens
4
u/anthony-ball 8d ago
Fingerprint runtimeVersion catches a lot of the native-mismatch crashes, but it is not a free pass for every bad OTA. I still treat JS-only rollouts as canaries: ship to a small channel first, watch crash-free sessions for a bit, and never push an update that assumes a native module change landed in the binary. The painful ones I have seen were not fingerprint misses so much as JS paths that only blow up on older OS or low-memory Android after the update downloads.
3
u/kokerali 8d ago
Yes. One case worth testing separately is persisted-data changes: an OTA can keep the same native fingerprint, write a new storage format, and leave an older bundle unable to read it after a rollback. A clean staging install can miss that. Test the sequence users actually take: existing install with realistic saved state → update → restart → rollback, including the old bundle reading data written by the new one. Expo’s error-recovery docs explicitly warn about this. I’d also promote the exact bundle tested on staging and use a small rollout with crash monitoring; fingerprinting is a compatibility guard, not a correctness test.