Expo Release Notes

Expo Go has recently been updated in the Apple App Store, and now supports projects running on Expo SDK 57. Expo Go users are now required to be logged in to both the Expo CLI running in your terminal and the Expo Go app in order to run your app in development mode.

If you are not logged in on either the terminal or in the app, when running

npx expo start

and scanning a QR code with your camera app, you may see one of the following messages:

The Expo Go app will tell you if you need to login on the terminal, the app, or both.

If you need to login on the terminal, run

npx expo login

and follow the link to login to your account in your web browser.

If you need to login on Expo Go, go to home, tap the avatar icon in the upper right corner and enter your Expo username and password to login.

Once you’re logged in on both sides, try scanning the QR code again (or tap the development server address on the Home tab) and your app should load.

Note that you will need to be logged in to the same account on both the terminal and in Expo Go.

This requirement currently only applies to the latest version of Expo Go for iOS, and will be extended to the Android version in the future. It does not apply to simulator versions. We recommend signing in to your account in Expo Go for Android, this automatically surfaces your running dev servers and allows you to load your published projects. Login is not required for development builds.

Original source

EAS Observe helps you understand how your app performs in the real world, with dashboards for app startup, navigation, EAS Update, and more. Today, August 20, 2026, it moves from public beta to general availability. No action is required to continue using Observe.

Every plan includes 90 days of data retention. The Free plan includes 100,000 events per month and access to the main Observe dashboard. Starter plans and above include 500,000 events per month and access to current and future observability dashboards. Starting today, usage beyond the included amount is billed at $5 per 1 million events for Starter plans and above.

You can see the full pricing table for Observe on our pricing page.

If you would like to manage event volume, you can adjust your project’s sample rate. You can also turn off data collection in your project’s settings, in the “Observe data ingestion” section.

You can get started with EAS Observe with our docs.

Questions or feedback about pricing? Let us know at [email protected].

Original source

The Expo MCP server is now in Claude's connector directory.

Add it at claude.ai/directory/connectors/expo, sign in with your Expo account once, and it stays connected. Thanks to the Anthropic team for reviewing the submission and getting us listed.

On a Claude Team plan you may see a Request button instead of Connect. That is expected, not an error. It sends the connector to your admins, who can enable it for the whole organization.

What a connector is, and what changes

You could always add the Expo MCP server by hand: a CLI command in your coding agent, or a URL in a config file. That still works, and existing setups keep working. The listing removes the setup step.

A connector is a hosted MCP server that Claude talks to over the network. You authorize it once and Claude can use its tools. A plugin is a bundle that packages skills, sub-agents, and MCP servers into one install. The difference is where each one runs: plugins run in Claude Code, in chat on the web and in the Claude Desktop Chat tab, and in Cowork. Connectors run in all of those plus the Claude mobile apps.

So one listing puts Expo everywhere Claude runs: claude.ai, Claude Desktop, Claude Mobile, Cowork, and Claude Code. Connect once and it is there in whichever one you open.

Prompts to try

Most of the tools never touch your repo. They talk to EAS and the app stores, so they work from a phone as well as a laptop. These work as typed:

• "Start a production iOS build and show me its status."
• "Submit the latest iOS build to TestFlight."
• "Any new TestFlight crashes since yesterday? Show me the stack trace."
• "Show me the latest TestFlight feedback from testers, with screenshots."
• "What are people saying in our recent App Store reviews?"
• "Reply to that 2-star review and apologize for the crash on launch."
• "Show me the latest ANRs from Google Play."
• "Run the deploy workflow and show me the logs."

The review reply tools write in public, so Claude shows you the text before it posts.

Plans and access

MCP usage is included on the Free plan. Paid plans get higher limits and earlier access to new capabilities. Usage counts per billing account, so members of an organization share one allowance.

What still needs your machine

In a coding agent like Claude Code, with an Expo project open, the same connector also searches the Expo docs and installs version-compatible packages.

Screenshots, tap automation, React Native DevTools, and the Expo Router sitemap need a dev server running next to your simulator. Setup for those has not changed. See the MCP docs.

Get started

Connect at claude.ai/directory/connectors/expo, or read the MCP docs for setup in each client. Tell us what you want the connector to do next. Find us in Discord or on X.

Original source

EAS Observe helps you understand how your app performs in the real world, with dashboards for app startup, navigation, EAS Update, and more. On August 20, 2026, it will move from public beta to general availability. Nothing changes today, and no action is required to continue using Observe.

At general availability, every plan will include 90 days of data retention. The Free plan will include 100,000 events per month and access to the main Observe dashboard. Starter plans and above will include 500,000 events per month and access to all current and future observability dashboards. Starting August 20, usage beyond the included amount will be billed at $5 per 1 million events for Starter plans and above.

You can see the full pricing table for Observe on our pricing page.

If you would like to manage event volume, you can adjust your project’s sample rate. You will also be able to disable event ingestion on your account or project before billing begins.

You can get started with EAS Observe with our docs.

Questions or feedback about pricing? Let us know at [email protected].

Original source

You can now add passkeys to your Expo account and use them to sign in. They can be managed at expo.dev/settings#sign-in-methods.

Passkeys are a primary authentication factor that is more secure than the combination of a password and OTP. Users who have 2FA enabled can use a passkey to sign in directly, without a second step.

Passkeys are not available to SSO users, as their authentication is managed through their organization's identity provider.

Learn more about passkeys at fidoalliance.org/passkeys.

Original source

Today we're announcing the release of Expo SDK 57. This is a small, focused release: it brings React Native 0.86 to Expo. We intend for this to be the easiest Expo SDK upgrade you've ever made. It represents a possible shift towards a new Expo SDK release cadence that could provide you with simple non-breaking upgrades in between more significant releases.

React Native 0.86

SDK 57 upgrades React Native from 0.85 to 0.86. The React version is unchanged from SDK 56 — both SDK 56 and SDK 57 use React 19.2. React Native 0.86 is intended to have no breaking changes from 0.85. To decide whether it's worth upgrading your app, refer to the React Native 0.86 release notes for the full picture.

Highlights include: fixes and improvements to edge-to-edge support on Android, light/dark mode emulation in React Native DevTools, and several rendering, layout, and animation-related fixes.

Exploring a new Expo SDK release cadence

For several years, Expo SDK has seen major releases three times per year. We found that this cadence provided a good balance between stability for app developers and freedom for our team to ship significant new features and improvements. It also helped to reduce thrash in Expo Go.

During the same period, React Native has been releasing six times per year. The React Native team prioritized shipping often in order to incrementally roll out the New Architecture, a new React Native DevTools experience, Hermes V1, and more. Each Expo SDK release would target a single React Native version, and for versions that were not targeted, developers could use canary releases if needed. However, now that these massive changes to React Native have shipped, the focus has shifted towards stability.

The new release model that React Native is moving towards will aim to provide a release with "no user-facing breaking changes" approximately every second release. The recently released 0.86 is the second of these non-breaking releases. At Expo, the fact that these releases are intended to be non-breaking has prompted us to revisit our release cadence. If we can provide these releases to developers almost immediately, as optional upgrades, with little effort required for the app developer beyond running npx expo install expo@latest --fix, then we think we should do it. So, we are exploring that approach with SDK 57.

Why not include React Native 0.86 in SDK 56 if it is non-breaking?

This is a good question! We considered bumping from 0.85 to 0.86 in SDK 56, and ultimately decided that the set of changes between the versions was too significant for an app developer to pull in with a routine npx expo install --fix. There are 601 commits touching 1,552 files between 0.85.0 and 0.86.0, and we believe that the decision to pull those into your app should be intentional. Even though these commits are intended to not cause breaking changes, we think it's best to err on the side of being conservative.

Additionally, moving this bump to a new SDK version allows us on the Expo team to roll out small changes that wouldn't be appropriate to ship to an existing stable release, but that we think are genuinely useful for users. The following list includes some of those changes that are worth calling out.

Does this new cadence impact the Expo SDK maintenance window?

SDK releases will continue to have a lifetime of approximately one year. We may revisit the details of this policy in the future. What this means today is that Expo SDK 54 (September 2025) will receive critical fixes until the next SDK release (September or October 2026).

Will there be a new Expo Go version on the App Store and Play Store?

We'd like to release a new version for SDK 57, but we're still waiting on approval. Expo Go for SDK 57 is available with eas go for iOS devices, and through Expo CLI for Android devices/emulators and iOS simulators (learn more).

Other highlights

While SDK 57 is primarily about the React Native 0.86 upgrade, a few other improvements landed alongside it:

• expo-dev-client: the iOS launcher includes a new setting to choose between auto-launching your most recent project or showing the launcher (#47131), allowing you to override the configuration set with the config plugin.
• expo prebuild: now clears and regenerates the native android and ios directories by default; pass --no-clean to apply changes to the existing folders instead (#47209).
• expo-image: added writeToCacheAsync and readFromCacheAsync to seed and read the image cache by cache key (#46620).
• expo-router: Stack.Toolbar.Badge is now supported in header left and right placements and on toolbar menu icons on Android (#46537, #47276).
• expo-navigation-bar: setStyle and setHidden now apply to React Native windows on Android (#46491).
• Bump animation and gesture libraries: SDK 57 bundles newer versions of react-native-reanimated (4.3 to 4.5), react-native-worklets (0.8 to 0.10), and react-native-gesture-handler (2.31 to 2.32).

Known regressions

• Increased memory usage with Hermes V1 and react-native-reanimated: importing react-native-reanimated can increase your app's memory usage by 25–30%, even if you don't actively use the library, due to a change in Hermes that shipped with React Native 0.85 (software-mansion/react-native-reanimated#9650). This also impacts SDK 56. As a workaround, enable worklets bundle mode. A fix is coming in Hermes V1 soon.

Upgrading your app

You should expect this to be a straightforward upgrade from SDK 56 / React Native 0.85, thanks to the absence of breaking changes in React Native 0.86.

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 57 from 56:

• Upgrade all dependencies to match SDK 57:

  npx expo install expo@^57.0.0 --fix
  

• Check for any possible known issues with Expo Doctor:

  npx expo-doctor@latest
  

• Make sure to check the changelog for all other breaking changes!
• 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:
  • 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.

Original source

Introducing a new insights dashboard

Introducing a new insights dashboard, showing you how every Maestro end-to-end test run performed over time, across your whole team. Identify flakey tests, see when regressions were introduced, and stop scrolling through endless logs.

Your end-to-end tests pass, until they don't. When a Maestro end-to-end (E2E) test fails, acting on it usually means digging through logs to find out what broke, re-running your whole suite to retry one flaky test, and guessing whether things are getting better over time.

Maestro insights collects and visualizes how your Maestro tests perform over time, right in your project's Insights tab. It surfaces:

• Trends: Maestro runs and pass rate across all your flows over time
• Flaky flows identification: flows that pass only after a retry, so you can find and fix the unreliable ones
• Failure patterns: failures grouped by error message, surfacing common causes behind failures
• Filter by test: open a specific test flow to see its recent runs, durations, and error patterns

With our insights, you can also filter by workflow, Git branch, tag, or status, and sort the flow list by runs, failures, flake rate, or P90 duration to find issues fast.

A clearer view of every run

Every Maestro job now opens with a Test Results summary that lists each flow along with its status (passed, failed, or flaky) and duration. Failed and flaky flows also surface their error messages at the top of the page, so you can immediately see what went wrong without digging through logs. Open the screenshot captured at the moment of failure or jump directly to the failure timestamp in the recording to quickly understand what happened.

Together with improved flaky test detection, these updates make it easier to identify issues, understand failures, and take action faster.

Retries that re-run only failed flows

When a Maestro job retries, it now re-runs only the flows that failed on the previous attempt instead of your whole suite. You’ll get faster feedback and fewer wasted CI minutes. This is the default behavior (retry_failed_only); to re-run every flow on each retry instead, set retry_failed_only: false. See the maestro job reference for details.

Built on JUnit output

Maestro insights, the Test Results summary, and failed-flow-only retries all build on the JUnit report the Maestro job produces by default (output_format: junit). If you've overridden output_format to another value, switch back to junit to use these features.

Get started

Maestro insights is currently available to Production (up to 30 days of history) and Enterprise plan (update to 1 year of history) subscribers. To see your project’s Maestro insights, open the Maestro tab in your project's Insights through the left sidebar. New to E2E testing on EAS? Follow our guide to running Maestro tests in EAS Workflows.

Original source

There are several ways to distribute iOS apps to your team: for devices, you can use TestFlight, ad hoc provisioning, or enterprise provisioning, and for simulators you can share a direct link to the build that can be installed manually or through Orbit. EAS makes it easy to use all of these approaches, so you can do what works best for any particular build or process. When distributing to devices, most developers will use some combination of TestFlight and EAS internal distribution with ad hoc provisioning.

With ad hoc provisioning, only devices listed in the profile at build time can install the build. So you need to register your device with EAS (which handles registering it with Apple), regenerate the profile, and then rebuild the app. This process has been difficult to automate in the past because the only way to refresh the profile was for a developer to manually run eas build or eas credentials. In other words, there was no way to refresh an ad hoc profile with --non-interactive or in EAS Workflows, so automated internal builds could succeed, but they would not install on a newly enrolled device.

We've shipped three updates to close that gap in automation:

• Ad hoc provisioning profile refresh on the CLI: --refresh-ad-hoc-provisioning-profile on eas build updates the ad hoc provisioning profile from Apple before a non-interactive build.
• Ad hoc provisioning profile refresh in workflows: refresh_ad_hoc_provisioning_profile: true on type: build jobs passes the same behavior through to the build worker.
• Device registration in workflows: the apple-device-registration-request job enrolls a physical device (QR code plus approval), then exposes its details to downstream jobs.

Together they support an automated loop: register and approve a device, refresh the profile so its UDID is included, then build an internal .ipa that installs on that device.

Refresh ad hoc provisioning profiles in CI

EAS CLI 19.1.0 added --refresh-ad-hoc-provisioning-profile. Use it with --non-interactive on an internal iOS build that uses EAS-managed credentials. Before gathering build credentials, EAS authenticates with your App Store Connect API key, reads devices registered on EAS for your Apple team, and creates or updates the ad hoc provisioning profile. The refreshed profile details are stored in EAS credentials and the build continues.

Example:

eas build --platform ios --profile preview --non-interactive --refresh-ad-hoc-provisioning-profile

Learn more about automating internal distribution on CI.

Refresh profiles in EAS Workflows

Workflows type: build jobs accept refresh_ad_hoc_provisioning_profile: true in params, the workflow equivalent of the CLI flag. EAS validates the job (iOS platform, internal profile, remote credentials) and passes the setting through to the build worker, which refreshes the profile before the build starts.

Example:

jobs:
  build_ios_internal:
    type: build
    params:
      platform: ios
      profile: preview
      refresh_ad_hoc_provisioning_profile: true

Request device registration in a workflow

The apple-device-registration-request job pauses the workflow until a developer enrolls and approves their physical iOS device. This is useful for ensuring a device is registered before downstream jobs run.

When the job runs:

1. The workflow run enters the "action required" state and shows a QR code in the dashboard.
2. A team member scans the code or opens the link on their iPhone or iPad and installs the registration profile.
3. A team member approves or rejects the enrollment on the workflow run page. (Enrollment alone does not advance the workflow; explicit approval is required for security.)

On approval, the job exposes outputs you can use downstream, including identifier (UDID), model, and software_version — useful in a downstream Slack job, for example. If your Expo account has multiple Apple teams, set apple_team_identifier in params; with exactly one team, it is optional.

Example:

jobs:
  register_device:
    type: apple-device-registration-request
    params:
      apple_team_identifier: ABCDE12345

End-to-end: register, approve, build

Together, device registration and profile refresh close the loop for internal iOS distribution in automation: enroll a device in the workflow, approve it, then build with profile refresh so the new UDID is on the provisioning profile.

Example:

name: Register device and build iOS internal
jobs:
  register_device:
    type: apple-device-registration-request
  build_ios:
    needs: [register_device]
    type: build
    params:
      platform: ios
      profile: preview
      refresh_ad_hoc_provisioning_profile: true

Original source

What you can do with Expo MCP

Connect your AI coding assistant to your Expo project from any Expo plan.

The Expo MCP Server is now available on the Free plan, with monthly MCP usage included for Free accounts. When we first launched the Expo MCP Server, it was available only on paid plans. Now anyone with an Expo account can connect an AI coding assistant to Expo docs and tools.

MCP (Model Context Protocol) is an open standard that lets AI assistants connect to external tools and project context. We introduced the Expo MCP Server in Become an AI-native developer with the Expo MCP Server; this update makes that workflow available to anyone with an Expo account.

Developers are already using Expo MCP for a few common workflows:

• Finding the right Expo answer faster. Your assistant can pull in official Expo documentation and SDK guidance while you are editing code.
• Debugging builds and workflows. It can inspect EAS build status, workflow runs, logs, failures, and related TestFlight crashes or feedback.
• Verifying app behavior locally. With a local dev server and simulator or emulator, it can take screenshots, tap through flows, inspect views, and collect logs.

Included Free-plan usage

Free accounts include monthly MCP usage intended to cover individual development, evaluation, prototypes, and occasional Expo-specific assistant help.

Usage is counted at the billing account level. If your account belongs to an organization, all members share the same included monthly usage. If the account reaches its monthly limit, MCP requests will fail with an error until usage is available again.

For heavier MCP usage, paid plans include higher usage limits and may include access to newer MCP capabilities before they are broadly available.

Get started and feedback

Follow the MCP docs to connect your AI coding assistant to Expo. MCP gives your agent access to Expo tools and project context; Expo Skills give it Expo-specific instructions for building, deploying, and debugging apps.

We'd like to hear what you want MCP and Skills to help with next. Checking whether a release is ready? Understanding update rollout health? Turning build, workflow, or TestFlight signals into concrete fixes? Find us in Discord or on X.

Original source

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 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 on Android, @expo/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.

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 hook hands you Material 3 Dynamic Colors that follow the system theme, and the Icon component pairs with @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 on SwiftUI and 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.
• 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 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 @gorhom/bottom-sheet, @react-native-community/datetimepicker, @react-native-masked-view/masked-view, @react-native-menu/menu, react-native-pager-view, @react-native-picker/picker, @react-native-segmented-control/segmented-control, and @react-native-community/slider APIs. Most migrations only require changing the import, though some props may be unsupported or differ because Expo UI is backed by SwiftUI and Jetpack Compose rather than UIKit and Android Views.

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 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.

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 reference and tutorial.

Revamped create-expo-module

In SDK 56, 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 configuration in expo-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.

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 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 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 and expo-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 component.

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

New Calendar, Contacts, and MediaLibrary APIs are now stable

With the release of Expo SDK 56, the next versions of the expo-calendar, expo-media-library, and expo-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 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.
• 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.
• import.meta support: now enabled automatically.
• Hermes v1 transforms: fewer bundler transforms are enabled for Hermes, which reduces bundling times overall.

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-/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):

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

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.
• In collaboration with 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 function for retrieving and setting metadata on initial page load. The existing component can still be used for updating metadata after hydration.
• We've also added two new helpers for data loaders: createStaticLoader and createServerLoader, 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 fallbacks in a _layout 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.

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 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.
• 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.

Other notable changes

• expo-audio: new useAudioStream hook for real-time microphone buffer access. Live-stream improvements: isLiveStream lock-screen option on iOS, playsInSilentMode on Android, and isLive / currentOffsetFromLive / error fields on AudioStatus.
• expo-haptics: web haptics on Safari.
• expo-asset: GLB model assets for 3D / AR work.
• expo-sqlite: native ArrayBuffer for blob columns, statement bind params, and session changesets — replacing the legacy JavaScriptArrayBuffer.
• expo-dev-launcher: error-screen "Copy" button, NDS service discovery on Android, Android edge-to-edge, and plugin options for defaultLaunchURL, skipOnboarding, and showMenuAtLaunch.
• 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.
• expo/fetch: brotli, gzip, and zstd response decompression on Android, and AbortSignal.timeout / AbortSignal.any support for WinterTC-compatible fetch behavior.

Deprecations

• @expo/vector-icons will be replaced by @react-native-vector-icons/*: the new scoped packages (one per icon set) are distinct from the older umbrella react-native-vector-icons package that @expo/vector-icons originally replaced. Migrate today by running npx @react-native-vector-icons/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.
• 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.
• Related to the planned deprecation of @expo/vector-icons, 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 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.

Known regressions

• Increased memory usage with Hermes V1 and react-native-reanimated: importing react-native-reanimated can increase your app's memory usage by 25–30%, even if you don't actively use the library, due to a change in Hermes that shipped with React Native 0.85. As a workaround, enable worklets bundle mode. A fix is coming in Hermes V1 soon.

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: npx expo install expo@^56.0.0 --fix
• Check for any possible known issues with Expo Doctor: npx expo-doctor@latest
• Refer to the "Deprecations" and "Notable breaking changes" sections above for breaking changes that are most likely to impact your app.
• Make sure to check the changelog 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.

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:

• 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, Sven.

Original source

We've made two changes to how Expo Go loads projects. First, when accessing updates published to EAS Update in Expo Go, you can now only load projects that you own or that are owned by an organization you are a member of. This change applies to all versions of Expo Go and took effect on May 12, 2026. Second, loading Hermes bytecode bundles (HBC) is only supported for EAS Update in Expo Go, and self-hosted updates must serve plain JavaScript bundles. This change applies to the latest versions of Expo Go for SDK 54, 55, and 56.

When distributing your app for review by your team, we recommend using the official store testing tracks, such as Google Play internal testing and TestFlight; internal distribution with EAS Build or any similar service that provides ad-hoc or enterprise provisioning support and archive hosting; or development builds in combination with EAS Update.

Learn more in "Overview of distributing apps for review".

Original source

The SDK 56 beta period begins today and will last approximately two weeks. The beta is an opportunity for developers to test out the SDK and ensure that the new release does not introduce any regressions for their particular systems and app configurations. We will be continuously releasing fixes and improvements during the beta period — some of these may include breaking changes.

SDK 56 beta includes React Native 0.85.2 and React 19.2.3. The full release notes for SDK 56 won't be available until the stable release, but you can browse the changelogs in the expo/expo repository to learn more about the scope of the release and any breaking changes. We'll merge all changelogs into the root CHANGELOG.md when the beta is complete.

Expo Go for SDK 56 on iOS simulators, eas go, and Android simulators and devices will be available later this week or early next week. For an update on the current status of Expo Go on the App Store, refer to "Expo Go and the App Store in May 2026".

We're also hosting office hours on Discord for those of you interested in helping test the release!

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 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 on Android, @expo/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.
• 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 on SwiftUI and 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 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-segmented-control/segmented-control, @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 builds with precompiled Expo packages

SDK 56 ships prebuilt XCFrameworks for our most complex Expo modules on iOS, to speed up your iOS builds. 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).

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!

Revamped create-expo-module

In SDK 56, 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.2 and React 19.2.3

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 configuration in expo-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.
• The Metro dev server now supports HTTPS via TLS configuration, enabling secure local development environments and compatibility with APIs that require secure origins.
• React Native 0.85 drops support for end-of-life (EOL) Node.js versions and releases before v20.19.4.

More capable expo-file-system

SDK 56 fills several parity gaps in the new expo-file-system 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 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 and expo-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 component.

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

New Calendar, Contacts, and MediaLibrary APIs are now stable

With the release of Expo SDK 56, the next versions of the expo-calendar, expo-media-library, and expo-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 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 skills docs for per-tool setup details.

Type-safe config plugins

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

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 bundler warmup: the time from expo start to a running bundling server is reduced — especially for monorepos with isolated dependencies, where we're seeing up to a 30% reduction in load time in the most extreme cases.
• watchFolders-free Metro experiment: eliminates watchFolders as a load-bearing configuration option, which also enables support for package manager global stores (such as in pnpm and bun) — useful in combination with Git worktrees. Enabled by default; disable it by adding experiment.onDemandFilesystem: false to your app.json.
• 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.
• Faster resolution: Module resolution has been sped up and the TypeScript resolution now has a lower impact on resolution times.
• import.meta support: import.meta support is now automatically enabled.
• Hermes v1 transforms: fewer bundler transforms are enabled for Hermes, which reduces bundling times overall.

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):

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

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.
• In collaboration with 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 function for retrieving and setting metadata on initial page load. The existing component can still be used for updating metadata after hydration. Check out the updated documentation and let us know how it works for you!
• We've also added two new helpers for data loaders: createStaticLoader and createServerLoader, 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 fallbacks in a _layout 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.

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 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.

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.

Other notable changes

• expo-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: web haptics on Safari (#44261).
• expo-asset: GLB model assets for 3D / AR work (#42495).
• expo-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: 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).

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 field in your package.json.

Deprecations

• @expo/vector-icons will be replaced by @react-native-vector-icons/: the new scoped packages (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 depreciation 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.

How to try out the beta release

Initialize a new project with SDK 56 beta

npm

• npx create-expo-app@latest --template default@next

bun

• bun create expo-app --template default@next

pnpm

• pnpm create expo-app --template default@next

yarn

• yarn create expo-app --template default@next

Note: create-expo-app will install dependencies with the package manager that you are using. For example, with npm when npx is used and yarn when yarn create is used.

Upgrade an existing project

Try using our expo/skills upgrade skills with Claude Code to upgrade your app to the beta. We appreciate reports for any issues that you encounter so we can further tune it in the coming weeks.

The following instructions explain the manual steps to upgrade your app.

• Upgrade all dependencies to match SDK 56:

  • npx expo install expo@next --fix

• Read the SDK 56 documentation for full API references.

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

What to test

• Upgrade and test: run npx expo install expo@next --fix, then consult the Native project upgrade helper and report any issues you encounter.
• Build natively: build with EAS Build, or if you have Xcode and Android Studio installed locally, try prebuilding and running: npx expo prebuild --clean and npm run ios and npm run android. Alternatively, try npx expo run. Any new issues? Please report them.
• Spot a docs gap? Let us know.

How to report issues

• Use the correct issue template: open an issue and fill out the appropriate template, and include a minimal reproducible example.
• Identify the root cause if you can: it's always super helpful and helps expedite a fix.
• Mention you're on the SDK 56 beta: we'll prioritize the issue accordingly.

Thank you for testing out the beta, we appreciate you!

Original source

How it works

You can now enable Gradle caching for your Android builds on EAS. This allows task outputs to be stored and reused between builds. We've observed around a 50% reduction in build times, with plans to continue improving from there!

Gradle's build cache stores task outputs so that when a task's inputs haven't changed, the result can be reused from cache instead of being recomputed. This is especially effective for projects with many native modules, where the same tasks are repeated across each module and can all be served from cache.

You can verify that caching is working by checking the Run Gradle step in your build logs. Cached tasks will be marked with FROM CACHE :

Get started

Set the EAS_GRADLE_CACHE environment variable to 1 to enable Gradle caching. You can do this from your accounts's environment variables settings, or by specifying it to your eas.json:

{
  "build": {
    "production": {
      "env": {
        "EAS_GRADLE_CACHE": "1"
      }
    }
  }
}

Once enabled, the initial build will generate and save the cache, and subsequent builds will restore from it. Cache keys are generated from the hash of your package manager lock file, so the cache is automatically updated as your dependencies change.

What's next

This is the latest addition to our build caching tools, following compiler cache for builds which uses ccache to accelerate C/C++ recompilation. Together, these caching layers can significantly reduce your build times on Android. We'll continue optimizing cache hit rates and plan to extend these improvements to further packages.

If you have any questions or feedback, reach out to us at [email protected]

Original source

You can now use your GitHub account to sign up or log in to Expo. Oh, and you may have received an email from GitHub. It’s legit.

You can now use your GitHub account to sign up or log in to Expo.

GitHub App Permissions

We require permission to view your email address in order to offer GitHub Sign In as an authentication method. If you already have Expo’s GitHub app authorized or installed, you likely received an email from GitHub requesting this permission on April 23, 2026 around 11:30AM PDT:

This is what the email from GitHub looks like.

If you would not like to set up GitHub Sign In on your Expo account, this email can be safely ignored. This does not affect existing integrations between GitHub and Expo.

If you would like to set up GitHub Sign In, link your GitHub account to your Expo account on the user settings page, and grant Expo permission to view your email address when prompted.

2FA

Signing in with GitHub does not bypass 2FA for logging in to Expo if set up.

CLI Authentication

To sign in with GitHub via the Expo CLI and EAS CLI, use the -b/--browser flag to open a browser-based login flow. Alternatively, you may create a password on the user settings page and log in through the CLI directly. Browser-based login is available on [email protected] and [email protected] (stable with SDK 55). It will soon become the default.

Original source

We're building Expo Observe, a new way to understand how your app performs in the real world.

The problem

You ship your app, but do you know how fast it actually launches for your users? What about users on older devices or slower networks? When you push an update, does performance improve or regress? Did adding all those new libraries slow down your app?

These questions are hard to answer without dedicated tooling, and existing solutions often require significant setup or don't integrate well with the React Native ecosystem.

Debugging performance in React Native has been a long-standing difficulty: a challenge the React Native team have recently addressed with the new DevTools and Performance panel, but these are development-time tools. With Observe, we focus on tracking performance in production.

What Expo Observe does

In this initial Preview release, we’ve focused on tracking startup metrics for your app:

• Cold Launch time: launch time when the app's native code and resources are not in memory
• Warm Launch time: launch time when native libraries, app's state and resources are already cached in memory
• Time to Interactive: when your app is ready for user input
• Time to first render: when content first appears on screen
• Bundle load time: how long it takes to load your JavaScript

How it works

Once integrated, Observe collects these metrics from real user sessions and gives you tools to understand them:

• Track across releases: compare performance between builds and OTA updates to catch regressions early
• Statistical breakdowns: view median, average, min, max, and percentile values (P90, P99) for each metric
• Investigate outliers: when something looks off, dig into individual sessions to see all events, device info, and metadata for that user

What's next

This is just the beginning. We're starting with startup metrics because they're critical to user experience and retention, but we have plans to expand Observe's capabilities based on what we learn from early testers.

We're looking for developers to help us test and shape Expo Observe. If you're interested in early access, please join the waitlist by filling out the form below.

Original source