Expo SDK 56: The Update That Finally Makes Builds Fast

I've upgraded a lot of Expo projects. Most SDK bumps are a chore — change a number, run install, fix three deprecation warnings, move on. SDK 56 is not that.

This one you'll actually feel. The first time I ran expo start after upgrading a mid-size client app, I thought the terminal had cached something. It hadn't. It's just that fast now.

Here's everything in SDK 56 that's worth your time, what to upgrade first, and the two or three things that'll break if you're not careful.

The speed numbers are the headline — and they're real

Expo went after build and dev performance hard this cycle. The receipts:

• expo start is ~5x faster and the Metro file crawl is 6x faster
• Cold bundling is 20-50% faster, warm bundling 3-8x faster
• Dev memory dropped 28% — your laptop fan will notice
• On Android, a new Kotlin compiler plugin cuts cold starts ~40% and first render 33%
• iOS clean builds shrink ~16% from precompiled XCFrameworks (about a minute off)

The runtime wins matter more than the dev wins, honestly. Activity.onCreate went from 93ms to 55ms. Time to Interactive dropped from 797ms to 531ms. That's the difference between an app that feels snappy and one that feels like it's thinking.

A big chunk of this comes from Hermes v1 shipping as the default engine — faster startup, less memory, better runtime. And expo-updates now diffs Hermes bytecode by default, which makes OTA patches 58% smaller on average. Your users download less, your updates land faster.

If you're still weighing whether Expo is the right tooling layer at all, I broke that down in my React Native with Expo vs React Native CLI guide — SDK 56 tilts that argument even further toward Expo. And if you're stuck deciding between a mobile build and a web app in the first place, the DSRPT team laid out the trade-offs in Web vs Mobile Applications: How to Choose the Right One.

Expo UI is stable — and it changes how you build native UI

This is the quiet big deal. The SwiftUI (iOS) and Jetpack Compose (Android) APIs in Expo UI are now stable. Not experimental. Not "use at your own risk." Stable.

What that gets you:

• Universal components — layout, text, inputs, controls, sheets — that work across iOS, Android, and web
• Drop-in replacements for 8 popular community libraries, including @gorhom/bottom-sheet and @react-native-community/datetimepicker
• A useMaterialColors hook for Material 3 dynamic colors, plus the full Material Symbols icon catalog
• react-native-worklets integration with a useNativeState hook for controlled inputs that don't lag

The practical upshot: fewer third-party dependencies, fewer version-mismatch headaches, and UI that actually looks native because it is native. I've shipped enough cross-platform apps to know that dependency sprawl is where projects rot. This trims it.

For the bigger picture on why I keep betting on this stack for client work, see Cross-Platform Excellence with React Native and Expo.

expo-router cut react-navigation loose

Heads up — this is a breaking change, but a healthy one. expo-router no longer depends on react-navigation. The team forked the parts it needed and now owns the stack.

Migrate with the codemod:

npx expo-codemod sdk-56-expo-router-react-navigation-replace [directory]

What you get in return:

• Streaming SSR on web with a generateMetadata function — real SEO for web routes
• New data loaders: createStaticLoader and createServerLoader
• Experimental Stack v5 with Material-style headers and predictive back gesture on Android
• Customizable SuspenseFallback directly in your _layout routes

Run the codemod, test your navigation flows, done. I hit one edge case with deeply nested modals — worth clicking through every screen before you ship.

That streaming-SSR-on-web piece is bigger than it looks. Expo apps can now render proper, SEO-friendly web routes — which puts them in the same conversation as the rendering tricks the DSRPT crew dug into in The Rise of Partial Pre-Rendering: Next.js 15 and the Future of Web Performance. If you've been treating React Native as mobile-only, the web story just got serious — and so did the case for Progressive Web Apps making a comeback.

The breaking changes you can't skip

Three things will bite you if you upgrade blind:

1. expo/fetch is now globalThis.fetch. It brings brotli/gzip/zstd decompression and AbortSignal.timeout. If something in your network layer assumes the old RN fetch behavior, opt out with EXPO_PUBLIC_USE_RN_FETCH=1.
2. @expo/vector-icons is deprecated. Move to the scoped packages — there's a codemod: npx @react-native-vector-icons/codemod. The expo package no longer pulls it in for you.
3. copy() and move() in expo-file-system are async now. Use copySync() / moveSync() if you need the old synchronous behavior.

None of these are hard. They're just the kind of thing that turns a 20-minute upgrade into a confusing afternoon if you don't know they're coming.

What else shipped that's actually useful

A few things that didn't make the headline but I'll use immediately:

• expo-file-system got serious. File.downloadFileAsync() with progress + AbortSignal, task-based createUploadTask() / createDownloadTask(), multi-file picking, and experimental File.watch().
• expo-audio added useAudioStream for real-time microphone access — voice features just got easier.
• expo-sqlite now handles native ArrayBuffer blobs and session changesets.
• iOS Widgets are stable with full environment access and proper timeline management.
• Type-safe config plugins with full TypeScript autocomplete, and support for local .ts/.mjs/.cjs plugin files.

And a sign of where the whole ecosystem is heading: new SDK 56 projects scaffold with AGENTS.md, CLAUDE.md, and .claude/settings.json out of the box, plus official Expo Skills for Claude Code, Cursor, and Codex. The tooling assumes you're coding with an AI agent now. That's not a gimmick — it's the new baseline. If you want to understand the protocol wiring all of this together, DSRPT's breakdown of MCP servers connecting AI to your business tools is the clearest one I've read.

TypeScript 6, and the React 19.2 connection

SDK 56 moves to TypeScript 6.0.3 and is already TypeScript 7-ready, with automatic import.meta support. If you've been tracking what landed in the language and the framework lately, my write-ups on React 19.2 and what's new in ES2025 pair well here — SDK 56 sits right on top of both.

Expo SDK 56 FAQ

What version of React Native does Expo SDK 56 use? Expo SDK 56 ships with React Native 0.85 and React 19.2. It also bumps TypeScript to 6.0.3, raises the iOS minimum to 16.4, and requires Xcode 26.4 or newer for native builds. Hermes v1 is now the default JavaScript engine.

Is Expo SDK 56 faster than SDK 55? Yes, significantly. expo start is roughly 5x faster, cold bundling improves 20-50%, and warm bundling is 3-8x faster. On Android, a new Kotlin compiler plugin delivers about 40% faster cold starts and 33% faster first render. iOS clean builds drop by around 16% thanks to precompiled XCFrameworks.

What are the breaking changes in Expo SDK 56? The main ones: expo/fetch replaces the global fetch (opt out with EXPO_PUBLIC_USE_RN_FETCH=1), @expo/vector-icons is deprecated in favor of scoped @react-native-vector-icons packages, expo-router no longer depends on react-navigation, and copy()/move() in expo-file-system are now async. Each has an official codemod to automate the migration.

Is Expo Go available for SDK 56? Expo Go for SDK 56 is not published on the App Store or Play Store at release. You install it through the Expo CLI on Android, via TestFlight External Beta on iOS, or with the eas go command. Most teams using custom native code should be on a development build anyway.

What to do now

Don't upgrade your production app on a Friday. Here's the order I'd run it:

1. Branch it. Bump the SDK version and run npx expo install --fix.
2. Run the codemods — expo-router and vector-icons first. They do the boring work.
3. Audit your fetch usage and file-system copy/move calls for the async changes.
4. Test on a real Android device to feel the cold-start improvement (and catch anything the Kotlin plugin shook loose).
5. Ship an OTA update and watch the smaller Hermes patch land.

If your app is more than a year old, the performance jump alone is reason to do this — and it might be a sign you're due for a broader refresh. I wrote about the signs it's time to upgrade your mobile app if you want a gut check before committing.

Building something cross-platform and want a second pair of eyes on the architecture before you scale it? That's exactly the kind of work the team takes on at DSRPT — and if you're not sure your idea even needs a custom build yet, start with 5 Signs Your Business Needs a Custom Web Application. Reach out if you'd rather get it right the first time than refactor it twice.