Expo SDK 56

Originally published on expo.dev/changelog
By Alan Hughes, Brent Vatne

---

Today we're announcing the release of Expo SDK 56. SDK 56 includes React Native 0.85 and React 19.2. Thank you to everyone who helped with beta testing.

Expo UI is now ready for production

As of SDK 56, the Jetpack Compose (Android) and SwiftUI (iOS) APIs in Expo UI are stable. We've added Expo UI to the default [create-expo-app](https://docs.expo.dev/more/create-expo/) template, so new Expo apps can use a rich set of native UI primitives right out of the box, and Expo UI is now available in Expo Go.

This milestone release builds on three SDK cycles of iteration across SDK 53, 54, and 55. Thank you to everyone on the Expo team and in the community who helped test, audit, and refine the APIs from the original SwiftUI prototype to the Jetpack Compose implementation.

SDK 56 focuses on three core pieces of Expo UI: a new universal components API for shared interfaces, stable native APIs, and drop-in replacements for popular React Native community libraries.

Universal components

Expo UI now includes universal components that work across Android, iOS, and web. Unlike the Android and iOS APIs, the web APIs are still experimental and likely to change.

The universal components are backed by [@expo/ui/jetpack-compose](https://docs.expo.dev/versions/v56.0.0/sdk/ui/jetpack-compose/) on Android, [@expo/ui/swift-ui](https://docs.expo.dev/versions/v56.0.0/sdk/ui/swift-ui/) on iOS, and react-dom or react-native-web on web. You can now build more cross-platform UI with Expo UI without splitting files into .android.tsx and .ios.tsx.

Universal components include layout primitives, text, inputs, controls, and sheets such as Host, Row, Column, ScrollView, Text, TextInput, Button, Switch, Slider, Checkbox, and BottomSheet. Learn more.

Stable native APIs

Expo UI's SwiftUI and Jetpack Compose APIs are now stable after several rounds of breaking changes. These changes align Expo UI more closely with the underlying frameworks, so developers and coding agents can lean on native platform documentation and examples directly when writing Expo UI code.

• Extend Expo UI with custom views and modifiers: you can now extend Expo UI with your own SwiftUI and Jetpack Compose views and modifiers. Expo UI manages layout synchronization, props, and events for you. See the guides for examples: SwiftUI guide and Compose guide.

• Material 3 Dynamic Colors and the Material Symbols catalog: the new [useMaterialColors](https://docs.expo.dev/versions/v56.0.0/sdk/ui/jetpack-compose/colors/) hook hands you Material 3 Dynamic Colors that follow the system theme, and the [Icon](https://docs.expo.dev/versions/v56.0.0/sdk/ui/jetpack-compose/icon/) component pairs with [@expo/material-symbols](https://www.npmjs.com/package/@expo/material-symbols) to bring the full Material Symbols catalog within import reach.

• **react-native-worklets**** integration and native state**: Expo UI now integrates with react-native-worklets and native state primitives from the underlying UI frameworks: [ObservableObject](https://developer.apple.com/documentation/combine/observableobject) on SwiftUI and [MutableState](https://developer.android.com/reference/kotlin/androidx/compose/runtime/MutableState) on Jetpack Compose. The new useNativeState hook lets JavaScript control that native state directly, which is useful for native state-driven animations and form controls. Learn more about useNativeState for SwiftUI and Jetpack Compose.

• Synchronous worklet callbacks: a new WorkletCallback shared object allows synchronous UI worklet callbacks to be passed as props to Expo UI views on both platforms. TextField on iOS and Compose can now use native state for value, and onValueChange accepts WorkletCallback, enabling synchronous, flicker-free controlled text inputs.

• Components, modifiers, and API changes: SDK 56 lands the bulk of the stabilization work since SDK 55. See the [@expo/ui](https://github.com/expo/expo/blob/main/packages/expo-ui/CHANGELOG.md) CHANGELOG for the full list.

Drop-in replacements for community components

Expo UI is focused on native primitives, and some of those primitives overlap with popular community libraries. To make migration easier and reduce library fragmentation, SDK 56 introduces drop-in replacements for several common community components.

For example, you can migrate from:

import DateTimePicker from '@react-native-community/datetimepicker';

to:

import DateTimePicker from '@expo/ui/community/datetime-picker';

Drop-in replacements are available for @react-native-segmented-control/segmented-control, @react-native-picker/picker, @react-native-community/datetimepicker, @react-native-masked-view/masked-view, and @gorhom/bottom-sheet APIs. Most migrations only require changing the import, though some props may differ because Expo UI is backed by SwiftUI and Jetpack Compose rather than UIKit and Android Views. Learn more.

Faster native builds

Precompiled Expo packages on iOS

SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS, to speed up your iOS builds. In our measurements, this cuts median clean iOS build times by around 1 minute (~16%) — both locally and on EAS Build. This is enabled by default both locally and on EAS Build — no configuration required. To opt out, set the EXPO_USE_PRECOMPILED_MODULES environment variable to 0 (for local builds), and also as an EAS environment variable (for EAS Build).

Precompiled headers for Android codegen (experimental)

A new opt-in android.usePrecompiledHeaders option in [expo-build-properties](https://docs.expo.dev/versions/v56.0.0/sdk/build-properties/) applies CMake precompiled headers to the C++ codegen output for every autolinked native module, dramatically cutting CMake compile times on Android. In our benchmarks, the :app:buildCMakeDebug task dropped from 17m 10s to 6m 06s — a 2.81x speedup. In a default new project, builds are about 1.3x faster. Results will vary by project, but the larger your autolinked module graph, the bigger the win.

Enable it in app.json:

// app.json
{
  "plugins": [
    ["expo-build-properties", { "android": { "usePrecompiledHeaders": true } }]
  ]
}

This feature is experimental in SDK 56 while we gather feedback, and we're working on upstreaming it to React Native so every app benefits from faster Android builds. Learn more in the PR.

Expo Modules: easier to write, faster to run

Inline modules

Starting with SDK 56, you can now define Expo modules directly within your project structure, alongside your JavaScript and TypeScript code. We call these inline modules, and they make experimenting with native code easier than ever.

After setting up your app to use inline modules, you can open Kotlin and Swift files and write your Expo modules with no additional setup. During prebuild, the iOS Xcode project is updated and the necessary options are set in the Android project, which lets us add inline modules to the build and autolink them automatically.

With the newly released type generation tools, which offer a few CLI commands tailored towards inline modules, you will have an even smoother experience. You can just create a Swift inline module and a CLI watcher will automatically generate a TypeScript interface for it right beside the Swift file. The TypeScript interface is separated into a generated and stable part, so that you have control over your stable TS interface and leave the generated part to be regenerated on any changes. If you want more control you can always generate these files manually.

You can develop inline modules from Android Studio, Xcode, or any other IDE as they are part of your project structure.

Check out the inline modules reference and the tutorial for more information!

Type generation tools

In SDK 56 we introduce a powerful new tool for developing Expo Modules. The new expo-type-information package exports functions that parse and retrieve type information from a Swift Expo module and ones that generate TypeScript interface from the retrieved information.

It also includes a CLI with the following key commands:

• module-interface: takes a Swift Expo module (accepting multiple file paths or a path to the module root) and generates multiple TypeScript files based on our standard interface scheme:

  • [ModuleName]Types.ts: contains all type declarations.
  • [ModuleName]Module.ts: contains the module class.
  • [ModuleName]View.tsx: exports the default view component(s) with typed props.
  • index.ts: re-exports the module alongside every defined type and view.

• inline-modules-interface: generates a pair of TypeScript files (generated, stable) for each Swift inline module in a project.

• short-module-interface: works similarly to inline-modules-interface, but targets a specific Swift module instead of all inline modules in the project.

All of these commands can be run in a watch mode to automatically regenerate the TypeScript interfaces.

Learn more in the [expo-type-information](https://docs.expo.dev/modules/type-generation-reference/) reference and tutorial.

Revamped create-expo-module

In SDK 56, [create-expo-module](https://docs.expo.dev/more/create-expo-module/) has been revamped for improved stability and a richer feature-set.

• New **`create-expo-module*`* skill**: helps agents create Expo modules — coming soon.

• New **`addPlatformSupport*`* subcommand**: adds support for additional platforms in an existing module — for example, adding Android support to an iOS-only module. The command detects the features currently used in your module and scaffolds the native files for you.

• Modular template: when creating a module you can pick which features get scaffolded and which platforms it targets.

• Non-interactive mode support: field defaults have been improved and some fields are no longer required; in non-interactive mode, create-expo-module logs the defaults that were used.

• No barrel file by default: local modules no longer use index.ts; pass --barrel to opt in.

• Windows support: create-expo-module now works well on Windows.

Runtime performance improvements in expo-modules-core

Kotlin compiler plugin — A new Kotlin compiler plugin replaces reflection with build-time code generation for Expo Modules on Android. In our benchmarks, we're seeing roughly 40% faster cold starts and 33% faster first render, with no app-side changes required. By collecting module metadata at compile time rather than runtime, we eliminate the reflection-based function-type-to-converter mapping that has historically been a major speed bump for Expo Modules on Android. Results will vary by project, but this is only the beginning — this compiler-driven approach lets us optimize function invocation directly, starting with a noticeable speed boost for Record conversion in SDK 56.

New JSI layer for iOS native modules — Until now, calling into a native module from JavaScript on iOS meant crossing three language boundaries: Swift, Objective-C++, and C++. In SDK 56 we removed the Objective-C++ middle layer entirely by adopting Swift/C++ interop to talk to JSI directly. Fewer hops means less call overhead, and in our benchmarks we're seeing significant performance improvements across native module calls. The codebase is also significantly easier to work with now that it is Swift all the way down. We'll cover the architecture, benchmarks, and what this enables in an in-depth blog post.

React Native 0.85 and React 19.2

Expo SDK 55 included React Native 0.83, so be sure to refer to the full release notes for 0.84 and 0.85 for the complete picture. A few highlights include:

• Hermes v1 by default: Hermes v1 is now the default JavaScript engine, bringing faster startup times, improved runtime performance, and reduced memory usage. You can opt out with the [useHermesV1](https://docs.expo.dev/versions/v56.0.0/sdk/build-properties/#sharedbuildconfigfields) configuration in [expo-build-properties](https://docs.expo.dev/versions/v56.0.0/sdk/build-properties/).

• New animation backend: React Native 0.85 introduces a new animation backend designed to better align with the New Architecture, improving consistency and performance of animations across platforms.

• HTTPS dev server: the Metro dev server now supports HTTPS via TLS configuration, enabling secure local development environments and compatibility with APIs that require secure origins.

• Node.js minimum bump: React Native 0.85 drops support for Node.js versions before v20.19.4.

Hermes bytecode diffing is now enabled by default

In SDK 55 we introduced opt-in Hermes bytecode diffing for expo-updates and EAS Update: instead of downloading a full bundle on every update, the client downloads a binary patch against the previously installed bytecode. In the 24 hours before this post went out, EAS Update served diffed Hermes bundles that were on average 58% smaller than the full bundle they replaced.

Diffing is on by default in SDK 56. To opt out, set "enableBsdiffPatchSupport": false in the updates block of app.json. Learn more in the [expo-updates](https://docs.expo.dev/versions/v56.0.0/sdk/updates/) API reference.

We're also working on extending bytecode diffing to patch against the embedded bundle shipped in your native build, not just against the previously installed update. This will give the first update after a fresh install the same size savings that subsequent updates already see. We're planning to ship this as an opt-in feature in an SDK 56 patch release in the coming months.

More capable **`expo-file-system**`

SDK 56 fills several parity gaps in the new [expo-file-system](https://docs.expo.dev/versions/v56.0.0/sdk/filesystem/) API that became the default in SDK 54. File.downloadFileAsync() now reports progress and supports AbortSignal, and copy/move operations accept an overwrite option.

The new API also adds task-based upload and download APIs: file.createUploadTask() and File.createDownloadTask(). These bring back support for long-running transfers from the legacy file-system module, including upload progress, cancellation, and resumable downloads. For simpler uploads, File.upload() provides a convenience wrapper when you do not need to manage an upload task directly.

File picking is more capable now too: File.pickFileAsync() supports selecting multiple files and multiple MIME types, bringing it closer to [expo-document-picker](https://docs.expo.dev/versions/v56.0.0/sdk/document-picker/) feature parity. We also fixed several correctness and reliability issues, including large-file md5 hashing memory usage, Android SAF copy/move support, and totalDiskSpace reporting on iOS.

We've also added experimental file-system event watching with File.watch() and Directory.watch(), which will let apps subscribe to file and directory changes without polling.

Status bar and navigation bar APIs are now consistent

Both [expo-status-bar](https://docs.expo.dev/versions/v56.0.0/sdk/status-bar/) and [expo-navigation-bar](https://docs.expo.dev/versions/v56.0.0/sdk/navigation-bar/) now expose a React component with the same prop surface, where multiple instances merge in mount order. To make that possible, we added a new <NavigationBar> component:

import { StatusBar } from 'expo-status-bar';
import { NavigationBar } from 'expo-navigation-bar';

const App = () => {
  useEffect(() => {
    // Imperative API
    StatusBar.setStyle('auto');
    StatusBar.setHidden(false);

    NavigationBar.setStyle('auto');
    NavigationBar.setHidden(false);
  }, []);

  return (
    <>
      {/* Declarative API: equivalent to the imperative calls above, with multiple instances merging in mount order */}
      <StatusBar style="auto" hidden={false} />
      <NavigationBar style="auto" hidden={false} />
    </>
  );
};

We also added a config plugin for expo-status-bar, and both packages' plugin options now align:

// app.json
{
  "plugins": [
    ["expo-status-bar", { "style": "light", "hidden": false }],
    ["expo-navigation-bar", { "style": "light", "hidden": false }]
  ]
}

New Calendar, Contacts, and MediaLibrary APIs are now stable

With the release of Expo SDK 56, the next versions of the [expo-calendar](https://docs.expo.dev/versions/v56.0.0/sdk/calendar/), [expo-media-library](https://docs.expo.dev/versions/v56.0.0/sdk/media-library/), and [expo-contacts](https://docs.expo.dev/versions/v56.0.0/sdk/contacts/) libraries are officially promoted to stable.

The updated APIs have been redesigned with an object-oriented approach. Items like media assets or individual contacts are now represented as classes, which unlocks new features and makes them much easier to work with. Key improvements include granular data fetching (instead of loading entire, heavy objects at once, you can now fetch the specific properties you need) and cleaner querying and filtering using the Builder pattern.

For more technical details and usage examples on the new MediaLibrary and Contacts APIs, check out the blog post.

Widgets for iOS promoted to stable

After introducing an alpha version of Expo Widgets for iOS in SDK 55, we gathered feedback and made many fixes and improvements, and the library is now stable. In SDK 56, Widgets and Live Activities have full access to the environment and no longer need to be pre-rendered. We also improved timeline management, error handling, the config plugin, and the render timeline.

AI-friendly project scaffolding

• Agent-ready scaffolding: new projects include AGENTS.md, CLAUDE.md, and .claude/settings.json with Expo-specific guidance.

• Official [Expo Skills**](https://docs.expo.dev/skills/) for AI agents**: install in Claude Code with /plugin marketplace add expo/skills followed by /plugin install expo. For Codex, Cursor, or any other agent, run npx skills add expo/skills. See the docs for per-tool setup details.

Convex integration

EAS now provisions and links Convex backends for you. Run eas integrations:convex:connect in your project and we'll install convex, create (or reuse) a Convex team linked to your EAS account, set up a project with a dev deployment, and write CONVEX_DEPLOY_KEY and EXPO_PUBLIC_CONVEX_URL to your .env.local. We also create EXPO_PUBLIC_CONVEX_URL as an EAS environment variable across Production, Preview, and Development so EAS Build picks it up automatically.

Expo CLI

SDK 56 ships the first wave of performance improvements across the whole bundling and run pipeline, with more landing in future releases.

• Faster CLI: Various performance metrics of the Expo CLI have been improved in SDK 56

• On-demand Filesystem: eliminates watchFolders as a load-bearing configuration option. Enabled by default; disable it by adding experiment.onDemandFilesystem: false to your app.json. Learn more in the PR.

• Native Node.js watcher by default: rather than Watchman, we now use a native Node.js watcher and crawler by default. You can switch back to Watchman with resolver.useWatchman in a Metro config, but it's no longer recommended.

• TypeScript 6 support and TypeScript 7 readiness: we replaced our TypeScript resolution to support TS 6 and prepare for TS 7. This resolves some monorepo bugs with tsconfig.json's paths config (#44791, #45227).

• **import.meta**** support**: now enabled automatically (#44239).

• Hermes v1 transforms: fewer bundler transforms are enabled for Hermes, which reduces bundling times overall (#45263, #45345).

With the On-demand Filesystem, you can also now try Expo with global virtual stores (such as in Bun and pnpm), which deduplicates installed Node modules across projects (saving ~300 MB per duplicate Expo install) and speeds up installs for agents working across multiple Git worktrees.

Type-safe config plugins

Every Expo package that ships a config plugin now exports it with full TypeScript types. Import the plugin from expo-<name>/plugin into your app.config.ts to get autocomplete, JSDoc, and deprecation hints for plugin options without leaving your editor.

Additionally, config plugins are now loaded with the same module loader that configs themselves use. This means you'll now also be able to reference local .ts files in your plugins list, or write config plugins with .mjs or .cjs extensions.

Expo Router

Expo goes way back with React Navigation: @brentvatne led the project for the 1.0 and 2.0 releases, working together with @ericvicenti and @satya164, and we helped to grow it from an idea, to a conceptual merging of React Native's old NavigationExperimental and ex-navigation, to the standard navigation library in the React Native ecosystem (now one of the standards, alongside Expo Router).

Today, React Navigation is in Satya's great hands, and our focus in the navigation space has shifted towards Expo Router. We spoke with Satya and agreed that the best path forward for both projects was for Expo Router to fork the parts of React Navigation that it builds around. You can, of course, continue to use React Navigation in your Expo projects if you find that you prefer it (try it out: npx create-expo-app@latest --template react-navigation/template). Both libraries build upon react-native-screens and have different takes on the developer experience, with Expo Router preferring file system-based routing. We expect that each library will continue to push the other forward in the future, and that the best ideas will continue to flow between them.

Now that expo-router no longer depends on react-navigation, most code imported directly from @react-navigation/* packages will no longer work out of the box alongside expo-router.

Run the codemod to handle most of the migration automatically (replace [your-source-directory] with your source folder, e.g. src or app):

See the migration guide for full details, including manual migration steps.

New features

• On Android, we've added experimental support for a toolbar. You can try it using the same API available on iOS: [Stack.Toolbar](https://docs.expo.dev/router/advanced/stack-toolbar/).

• In collaboration with [react-native-screens](https://github.com/software-mansion/react-native-screens), we've also introduced experimental support for a new version of the native stack (Stack v5), including initial support for Material-style headers and predictive back gesture.

• For Expo on the Web, we now support streaming SSR when using the unstable_useServerRendering flag. As part of this change, we've also introduced a new [generateMetadata](https://docs.expo.dev/router/web/server-rendering/#metadata) function for retrieving and setting metadata on initial page load. The existing <Head> component can still be used for updating metadata after hydration. Let us know how it works for you!

• We've also added two new helpers for data loaders: [createStaticLoader](https://docs.expo.dev/versions/v56.0.0/sdk/server/#createstaticloaderfn) and [createServerLoader](https://docs.expo.dev/versions/v56.0.0/sdk/server/#createserverloaderfn), which narrow the callback signature for each rendering mode. createStaticLoader receives only route params (no request), while createServerLoader always passes a request and throws an actionable error if mistakenly used during static generation.

• We've also added the ability to customize the default [<Suspense>](https://docs.expo.dev/router/error-handling/#loading-states-with-suspense-fallback) fallbacks in a [_layout](https://docs.expo.dev/router/error-handling/#loading-states-with-suspense-fallback) route, giving you more control over loading states across your app. Following the same convention as ErrorBoundary, you can export a SuspenseFallback that receives route parameters, making it easy to show loading UI:
  

import { ActivityIndicator, View } from 'react-native';
import { Stack } from 'expo-router';

export function SuspenseFallback() {
  return (
    <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
      <ActivityIndicator size="large" />
    </View>
  );
}

export default function RootLayout() {
  return <Stack />;
}

Brownfield: more flexibility for embedded Expo apps

SDK 56 builds on the brownfield foundation we shipped in SDK 55, with three meaningful additions for teams embedding Expo into existing native apps.

Multiple isolated apps in one host. A new experimental option lets one host app contain multiple inner [expo-brownfield](https://docs.expo.dev/versions/v56.0.0/sdk/brownfield/) apps. Opt in by setting multipleFrameworks: true on the iOS plugin config, and each framework gets a unique Swift module name plus an auto-applied ObjC symbol prefix across its entire pod dependency graph, so two brownfield apps can ship side by side without colliding.

// app.json
{
  "plugins": [
    [
      "expo-brownfield",
      {
        "ios": {
          "multipleFrameworks": true
        }
      }
    ]
  ]
}

Custom Turbo Modules from the host app. Host apps can now register their own turbo module classes with the inner Expo app's React Native runtime, by passing a turboModuleClasses dictionary into ReactNativeHostManager.initialize. This makes it much easier to expose host-app capabilities (auth, app-specific SDKs, native UI controllers) to JavaScript without modifying the inner app's bundle.

iOS prebuilds by default. expo-brownfield now uses prebuilt React Native frameworks on iOS out of the box, which substantially cuts brownfield build times. If you need to opt back into building React Native from source, use the new buildReactNativeFromSource plugin option.

Expo Application Services (EAS)

Build time statistics for xcodebuild and Gradle

EAS Build now surfaces per-step timing for xcodebuild and Gradle, so you can see exactly where your native build time is spent and decide what to optimize first.

Prebuilt artifacts for major community libraries

Building on the precompiled Expo packages work in SDK 56, EAS Build now precompiles some of the most commonly used community libraries in the React Native ecosystem too — like react-native-reanimated and react-native-screens. In our measurements, this cuts median iOS clean build times on EAS Build by another ~1 minute (~20%) on top of the Expo-modules precompile, with bigger savings for apps that use more of these libraries.

Coming soon: EAS Observe

We're working on EAS Observe, a production performance monitoring service for Expo apps that tracks real-world metrics on your users' devices. Compare metrics across releases to catch regressions early, then investigate detailed session data (on your own, or hand it off to an LLM) when something looks off. Kadi Kraman shared a deeper preview at App.js Conf — keep an eye out for the recording.

Other notable changes

• [**expo-audio**](https://docs.expo.dev/versions/v56.0.0/sdk/audio/): new useAudioStream hook for real-time microphone buffer access (#44902). Live-stream improvements: isLiveStream lock-screen option on iOS (#43088), playsInSilentMode on Android (#43117), and isLive / currentOffsetFromLive / error fields on AudioStatus (#44441).

• [**expo-haptics**](https://docs.expo.dev/versions/v56.0.0/sdk/haptics/): web haptics on Safari (#44261).

• [**expo-asset**](https://docs.expo.dev/versions/v56.0.0/sdk/asset/): GLB model assets for 3D / AR work (#42495).

• [**expo-sqlite**](https://docs.expo.dev/versions/v56.0.0/sdk/sqlite/): native ArrayBuffer for blob columns (Android #42640 / iOS #42642), statement bind params (#42639), and session changesets (#42638) — replacing the legacy JavaScriptArrayBuffer.

• [**expo-dev-launcher**](https://docs.expo.dev/versions/v56.0.0/sdk/dev-client/): error-screen "Copy" button (#44723), NDS service discovery on Android, Android edge-to-edge (#44529), and plugin options for defaultLaunchURL (#44419), skipOnboarding, and showMenuAtLaunch (#45167).

• **expo-doctor**: a new check warns when expo-router and react-navigation are both installed — a likely unintended pairing now that expo-router no longer sits on top of react-navigation (#45323).

• [**expo/fetch**](https://docs.expo.dev/versions/v56.0.0/sdk/expo/#expofetch-api): brotli, gzip, and zstd response decompression on Android (#45458), and AbortSignal.timeout / AbortSignal.any support for WinterTC-compatible fetch behavior (#45441).

Deprecations

• **@expo/vector-icons**** will be replaced by `@react-native-vector-icons/**: the new [scoped packages](https://github.com/oblador/react-native-vector-icons) (one per icon set, e.g. @react-native-vector-icons/material-design-icons) are distinct from the older umbrella react-native-vector-icons package that @expo/vector-icons originally replaced. @expo/vector-icons was created for Expo Go compatibility; recent upstream work has made that wrapper unnecessary, so consolidating onto @react-native-vector-icons/ reduces duplication and gives you the latest icons and fixes directly. Migrate today by running npx @react-native-vector-icons/codemod` — Learn more about the codemod.

• Original **`expo-calendar*`, ***expo-contacts**, and **`expo-media-library*`* APIs**: superseded by the redesigned versions now promoted to stable — the original APIs are deprecated.

Notable breaking changes

• **expo/fetch**** as `globalThis.fetch*: expo/fetch is now installed as the default implementation of globalThis.fetch, providing a WinterTC-compliant API and improved performance. Manual imports are no longer required. To opt out, set EXPO_PUBLIC_USE_RN_FETCH=1` in your *.env** file. Learn more.

• Async **`copy()` and `move()` in `expo-file-system**: these methods on File and Directory are now asynchronous and return a Promise. Use copySync() and moveSync()` for synchronous behavior.

• **@expo/dom-webview**** as the default WebView for DOM components**: you no longer need the react-native-webview dependency to use DOM components. You can still opt out and continue using react-native-webview if needed. Learn more in the usage guide.

• Related to the planned deprecation of @expo/vector-icons (see the previous paragraph), the expo package no longer depends on @expo/vector-icons. If you wish to continue using @expo/vector-icons, you need to explicitly add it to your project's dependencies in package.json.

Tool version bumps

• Minimum Xcode bumped to 26.4.

• Minimum iOS / tvOS bumped to 16.4, macOS to 13.4. Up from iOS 15.1 (last bumped August 2024). Drops support for iPhone 7/7+, iPhone 6s/6s+, iPhone SE (1st gen), iPad mini 4, and iPad Air 2.

• TypeScript bumped to 6.0.3 — included in new project templates and pulled in for existing projects via npx expo install --fix. To opt out, add typescript to the [expo.install.exclude](https://docs.expo.dev/versions/v56.0.0/config/package-json/#installexclude) field in your package.json.

Expo Go

Reminder: The Expo Go app is our tool for getting started quickly, it's an educational tool to help you learn to build on mobile. If you are past that stage and want to build and ship an app, we encourage you to migrate your project to using a development build.

Expo Go for SDK 56 is not available on the Apple App Store or Google Play Store. We do not have a timeline for when they will be, and we'll update this post when we have more news to share.

• You can install Expo Go for SDK 56 from Expo CLI directly on Android devices.

• For iOS, you can use the TestFlight External Beta or the eas go command to create an Expo Go build for SDK 56 and upload it to your own TestFlight team.

Upgrading your app

Try using our upgrade skills (installation instructions) with Claude Code, or a similar tool of your choice, to upgrade your app.

Here's how to upgrade your app to Expo SDK 56 from 55:

• Upgrade all dependencies to match SDK 56:

• Check for any possible known issues with Expo Doctor:

• Refer to the ["Deprecations"**](#deprecations) and ["Notable breaking changes"](#notable-breaking-changes) sections** above for breaking changes that are most likely to impact your app.

• Make sure to check the [changelog**](https://github.com/expo/expo/blob/main/CHANGELOG.md) for all other breaking changes!**

• Upgrade Xcode if needed: Xcode 26.4 is required to compile a native iOS project. For EAS Build and Workflows, profiles without any specified image will default to Xcode 26.4.

• iOS deployment target bump: if you have any Expo modules of your own, update the iOS deployment target to 16.4 in your podspec.
  

- s.platforms = { :ios => '15.1' }
+ s.platforms = { :ios => '16.4' }

• *If you use *Continuous Native Generation:

  • Delete the android and ios directories if you generated them for a previous SDK version in your local project directory. They'll be re-generated next time you run a build, either with npx expo run:ios, npx expo prebuild, or with EAS Build.

• If you **don't** use [Continuous Native Generation**](https://docs.expo.dev/workflow/continuous-native-generation/):

  • Run npx pod-install if you have an ios directory.
  • Apply any relevant changes from the Native project upgrade helper.
  • Optionally, you could consider adopting prebuild for easier upgrades in the future.

• *If you use *development builds with expo-dev-client: Create a new development build after upgrading.

• If you use Expo Go: consider migrating to development builds. Expo Go is not recommended as a development environment for production apps.

• Having trouble? Refer to the Troubleshooting your SDK upgrade guide.

• Questions? Join our weekly office hours on Wednesdays at 12:00PM Pacific on Discord.

Thanks to everyone who contributed to the release!

Thanks to the Expo team — everyone contributed one way or another.

External contributors: Abhishek Raj, Aleksandr Kondrashov, Alfonso Curbelo, Amaury Liet, Andrej Pavlovic, Arthur Blais, Artur Morys - Magiera, Azeem Idrisi, azro352, benjamin, Benjamin Komen, Benjamin Wallberg, Błażej Kustra, C. Obama, CamWass, Choco, Chris Masters, Chris Zubak-Skees, Christian Wooldridge, Cristian C., Dalibor Belic, Daniel Meyer, Daniel Reichhart, Danish, Dave Mkpa-Eke, Delphine Bugner, Dennis Morello, desii, Dimitar Nestorov, Doğukan Yıldız, Donghoon Nam, Dwight Watson, Dylan, Emil Lindén, Eric Kreutzer, Eric Zeiberg, Fernando Rojo, Frank Calise, Gary Chiu, Gregory Moskaliuk, Gustavo Harff, Hugo Extrat, Ian K, Isaiah Hamilton, Jakub Kosmydel, Jc Cloete, Jeroen van Warmerdam, JeroenG, Jesper Sørensen, John HU, Jonathan Baudanza, Jonathan Rivera, Joseph Gift, Julie Saia, jurajpaska8, K.Dileepa Thushan Peiris, Kazuho Maejima, Kfir Fitousi, kimchi-developer, Kornelijus Šliubauskas, Kræn Hansen, Krastan Dimitrov, Kyle Ledbetter, Leonardo E. Dominguez, leonmetthez, Loic CHOLLIER, lucabc2000, Lucia Sarni, Manu, Matin Zadeh Dolatabad, Matthew Abraham, Mauko Quiroga-Alvarado, Maxime, Mikołaj Szydłowski, Mohammad Amin, Momtchil Momtchev, Myagmarsuren, Nicholas Pachulski, Nick Ater, Nicola Corti, Otávio Stasiak, Patrick Michalik, Patrick Wang, Patryk Mleczek, Peter Lazar, Petr Chalupa, Pflaumenbaum, Preet Patel, Randall71, Regi24, roach, Rodrigo Leite Araujo, Ronald Goedeke, Samuel Brucksch, Samuel Newman, Satyajit Sahoo, Sergiy Dybskiy, Serhii Pustovit, Shane Friedman, Shoghy Martinez, Shubh Porwal, Shubham Shinde, snowingfox, starsky-nev, teamclouday, Terijaki, TheUntraceable, ThiMal, Tomasz Zawadzki, Ty Rauber, Victor Bolivar De la Cruz, Vsevolod Lomovitsky, xoyseau, yerevin, and Zhovtonizhko Dmitriy.

Beta testers: Agrit Tiwari, Amrit Saini, androidanimation, Anthony Mittaz, Berhan, Brandon Austin, David Grimsley, dylanfcsr, Eduardo Lomelí, ifx326, Kenji Okura, Kingfapa, Lucas Hardt, Matthew Horan, Max, Robrecht Meersman, Rodolfo Perottoni, Simon, and Sven.