Upgrades fail at the edges
The SDK bump itself is usually not the dangerous part. The risky part is everything attached to it: auth callbacks, purchases, notifications, analytics, and release configuration.
The checklist
Read the Expo release notes and list every native-facing dependency in your app
Upgrade dependencies with the official Expo installer before hand-editing versions
Smoke-test sign in, sign up, password reset, and OAuth callbacks
Verify paywall, purchase, entitlement restore, and account management flows
Send a test push notification on both iOS and Android
Check analytics, screen tracking, and error reporting after the upgrade
Build at least one simulator/dev build before touching production profiles
Test a cold app launch, background resume, and deep-link entry path
Record any required docs updates while the context is still fresh
Only then queue the preview or production release
What to test first
If time is tight, test the revenue path and the login path before anything else. Those are the two flows most likely to hurt trust and revenue if the upgrade introduces subtle breakage.
The cleanest team habit
Keep a reusable upgrade note in your repo and append to it on every upgrade. That way the next upgrade starts from your last reality, not from a blank page.
Make upgrades feel routine
Shipnative keeps the mobile product stack coherent so you can validate the important flows quickly every time a new Expo SDK lands.
Get Started Now