Expo SDK 56 Is Out, and a Few Things Finally Clicked Into Place

Manthan Kasle — Sat, 23 May 2026 17:55:12 +0000

React Native 0.85, much faster builds, and the one change that will probably break your imports._

Based on the official release notes: expo.dev/changelog/sdk-56

SDK 56 dropped on May 22, and I spent the weekend pulling one of my apps onto it. Most release notes read like a wall of changelog entries, so instead of repeating all of that, I want to walk through the handful of changes that actually show up in your day to day.

Quick version up top: SDK 56 ships React Native 0.85 and React 19.2. If you came from SDK 55 you skipped 0.84, so this is two RN versions in one jump.

Builds got faster, and you don’t have to do anything

I noticed it before I even opened the changelog.

On iOS, the heaviest Expo modules now ship as prebuilt frameworks. No config change, it just happens, locally and on EAS. Expo measured around a one minute cut on median clean builds, roughly 16 percent. EAS goes a step further and precompiles common community libs like Reanimated and Screens too, which stacks another minute or so on top.

Android got the bigger architectural win. A new Kotlin compiler plugin replaces the old reflection based module setup with metadata generated at build time. The numbers Expo published: cold starts about 40 percent faster, time to interactive 1.5x, onCreate 1.7x. Nothing for you to wire up, you just get it on upgrade.

There’s also an experimental flag for Android codegen using precompiled headers. In their benchmark a CMake task dropped from 17 minutes to 6. It’s off by default and you opt in through expo-build-properties, so worth a try if your build graph is heavy.

Hermes v1 is the default now

Faster startup, lower memory, better runtime. If something breaks you can flip useHermesV1 back off in expo-build-properties, but I'd leave it on and see how it goes.

One thing to check before you start: Node below v20.19.4 is no longer supported. Look at your CI image first, or you’ll waste twenty minutes wondering why nothing installs.

Expo UI is stable

After three SDK cycles, the SwiftUI and Jetpack Compose APIs in Expo UI are stable and in the default template. There’s now a universal component set (Host, Row, Column, Text, TextInput, Button, Switch, Slider, and a few more) that runs on iOS, Android, and web without splitting files into .ios.tsx and .android.tsx. Web is still experimental though, so don't lean on it for production yet.

The part I actually like is the drop in replacements for community libraries. You change the import and move on:

// before
import DateTimePicker from '@react-native-community/datetimepicker';
// after
import DateTimePicker from '@expo/ui/community/datetime-picker';

Same idea works for the bottom sheet, picker, segmented control, masked view, and slider. Some props differ because it’s backed by SwiftUI and Compose instead of UIKit, so read the docs before swapping everything blindly.

The one that will bite you: expo-router split from react-navigation

Expo Router forked the navigation primitives it used to borrow from React Navigation. It still sits on react-native-screens, and React Navigation is still fully supported if you prefer it. But if your code imports directly from @react-navigation/* inside an Expo Router project, those imports break.

There’s a codemod that handles most of it:

npx expo-codemod sdk-56-expo-router-react-navigation-replace [your-source-dir]

expo-doctor will also now warn you if you have both expo-router and react-navigation installed, since that combo is usually a mistake after this change.

expo-file-system caught up

The new file-system API became the default back in SDK 54, and it had gaps. SDK 56 closes most of them. Downloads report progress and can be cancelled with AbortSignal, copy and move take an overwrite flag, and there are proper task based upload and download APIs with progress and resumable transfers. File picking handles multiple files and MIME types in one call now too.

If you held off moving from the legacy module because of missing features, this is probably the release where you stop holding off.

Smaller things worth knowing

Calendar, Contacts, and MediaLibrary APIs are now stable, with an object based design. The old ID based APIs are deprecated.
iOS Widgets and Live Activities are stable.
expo/fetch is now the global fetch. Usually invisible, but set EXPO_PUBLIC_USE_RN_FETCH=1 if you need the old behavior.
copy() and move() in file-system are async now. Use copySync() and moveSync() if you depended on the sync versions.
New projects scaffold AGENTS.md and CLAUDE.md, plus official Expo skills for Claude Code and the other agents.

Version bumps to plan for

Minimum iOS is now 16.4, up from 15.1. That drops some old devices like the iPhone 7 and the first gen SE.
Xcode 26.4 is required to compile native iOS.
TypeScript moves to 6.0.3.

Expo Skills, and why I let an agent do the upgrade

I didn’t expect to care about this one.

Expo now ships official Skills for AI agents. If you haven’t run into Skills yet, they’re structured instruction files that teach an agent the correct way to do a specific Expo task instead of letting it improvise from half remembered docs. They work with Claude Code, Cursor, Codex, and the others. New SDK 56 projects even scaffold AGENTS.md and CLAUDE.md for you.

Install them in Claude Code:

/plugin marketplace add expo/skills
/plugin install expo

For any other agent, the skills CLI does the same job:

npx skills add expo/skills

There’s a long list (building native UI, deployment, dev client, modules, EAS workflows, brownfield, and more), but the one that matters for this post is [upgrading-expo](https://github.com/expo/skills/blob/main/plugins/expo/skills/upgrading-expo/SKILL.md). It handles SDK upgrades as an actual sequence rather than a single command: it reads your package.json, runs the install with --fix, walks the breaking changes, validates your config plugins, checks native module compatibility, and flags the bits it can't safely auto-fix. It also carries migration references for the trickier moves like the New Architecture, React 19, native tabs, and expo-av to expo-audio/expo-video.

The Expo docs straight up recommend it now: if you use a coding agent, install Skills and run the [upgrading-expo](https://github.com/expo/skills/blob/main/plugins/expo/skills/upgrading-expo/SKILL.md) skill rather than upgrading by hand. The full list lives at docs.expo.dev/skills.

Upgrading

If you’d rather drive it yourself, for an app on 55:

npx expo install expo@^56.0.0 --fix
npx expo-doctor@latest

Then read the breaking changes section twice before you push, bump your iOS deployment target to 16.4 in any custom module podspecs, and make a fresh dev build if you use expo-dev-client.

For my upgrade I let the [upgrading-expo](https://github.com/expo/skills/blob/main/plugins/expo/skills/upgrading-expo/SKILL.md) skill take the first pass, then went through the diff myself. It caught the react-navigation imports and the async copy/move changes before I hit them at runtime, which is exactly the kind of thing you forget when you're moving fast. The router codemod did the rest of the heavy lifting, and the build speed difference on EAS was real, not a benchmark you only see in a blog post. If you maintain a production app, this is one of the more worthwhile jumps in a while.

DEV Community: Manthan Kasle