Upgrade Expo SDK safely: reproduce it in a sandbox first

Expo SDK upgrades are mostly smooth. "Mostly" is the problem when you're responsible for several production apps at once. When one goes wrong, you want to find out in a repo that doesn't matter.

So we have a habit: on the day a new SDK ships, we spin up a disposable sandbox, a fresh create-expo-app pinned to the exact version, and nothing else.

npx create-expo-app@latest expo-sdk54 --template blank-typescript
cd expo-sdk54 && npx expo install --check

What the Expo SDK upgrade sandbox is for

Reproducing reported regressions. When the community reports something, like the Android cold-start slowdown people reported after the SDK 52 upgrade (which turned out to be mostly a measurement change), we check whether it shows up in a clean app before we assume it will affect ours.
Separating "Expo" from "our app." If a problem appears in the blank sandbox, it's upstream. If it only appears in the client app, it's ours: a native module, a config plugin, a build setting. That split saves hours.
A minimal repro, ready to go. If we need to file or comment on an upstream issue, we already have the smallest possible project that shows it.

Why a separate repo

It's tempting to test upgrades on a branch of the real app. The trouble is that a real app has dozens of dependencies, each with its own opinion about the new SDK. The first failure you hit is often a third-party library, and it masks whatever else is wrong.

A blank project gives you a baseline. Then you add dependencies back one at a time until something breaks, and you know exactly what broke it.

It's a small ritual, but it has turned SDK upgrades from a risk into a checklist.