Expo SDK 52 Android cold start: regression, or did the stopwatch move?
In 2025, React Native Android cold start looked much worse after Expo SDK 52. A careful investigation showed the metric changed, not the app.
From 2025 · 2 min read · Published September 13, 2026
In 2025, while getting several client apps ready for newer Expo SDKs, we kept running into the same worrying report: Android cold start times appeared to have jumped after Expo SDK 52. If true, that was a reason to hold upgrades.
Before deciding anything, I dug into the best investigation I could find, a set of controlled test apps by Jakub Grzywacz, which I forked to study and rerun. It's one of the cleaner examples I've seen of a performance "regression" that turned out to be a change in what was being measured.
What changed in Expo SDK 52
Android reports cold start as the time from process start until the splash screen is gone.
Before SDK 52, expo-splash-screen faked the splash screen. The native splash disappeared quickly, and a JavaScript overlay that looked identical took its place until the app was ready. Android's measurement stopped at the native splash, so it never included the overlay time.
From SDK 52, the package uses Android's real Splash Screen API and simply extends the native splash until you call SplashScreen.hideAsync(). That's the right behavior. It also means the measurement now includes all the time your app spends loading fonts, reading storage, or fetching a user before it hides the splash.
The numbers
The investigation compared release builds of SDK 51 and SDK 53, three runs each:
| Scenario | SDK 51 avg (ms) | SDK 53 avg (ms) | Change |
|---|---|---|---|
| Default | 336.67 | 281.33 | -16.44% |
| Instant hide | 360 | 336 | -6.67% |
| Hide after a 2s delay | 305.33 | 2365.33 | +674.68% |
The first two rows show the app got faster. The last row is the "regression": with a deliberate two second delay before hideAsync(), SDK 51 didn't count those seconds, and SDK 53 does. The app didn't slow down. The stopwatch moved.
What we took from it
- Your metric is now honest, so treat it that way. Measured cold start now includes the work you do before hiding the splash. That's closer to what users actually feel. If the number looks bad, the fix is in your startup path, not in the SDK.
- Hide the splash as early as you honestly can. Load only what the first screen truly needs. Fetch the rest after it renders.
- Before blaming an upgrade, check what the metric measures. Compare a blank app on both versions first. If the blank app got faster and yours got slower, the difference is in your code.
Credit to Jakub for doing the careful work. The most useful performance investigations are often the ones that end with "it's fine, here's why."
Related: Upgrade Expo SDK safely: reproduce it in a sandbox first · Hash the native layer: skipping React Native builds before Expo Fingerprint