DEV Community: Expo

Control SwiftUI and Compose State Synchronously with Worklets in Expo UI

Dan — Thu, 28 May 2026 20:20:50 +0000

React Native developers have long dealt with the friction of bridging JavaScript with native UI threads. Every time you need to update native state, you send a message across the bridge, wait for the round-trip, and hope the user doesn't notice the delay. Expo UI in SDK 56 changes this with worklet integration.

You can now control SwiftUI and Compose state directly on the UI thread, with zero JavaScript round-trips. Here's what that looks like:

import { Host, TextInput, useNativeState } from '@expo/ui';

export default function Screen() {
  const value = useNativeState('');

  return (
    <Host matchContents>
      <TextInput
        value={value}
        placeholder="Type something"
        onChangeText={(value) => {
          'worklet';
          // Runs synchronously on the UI thread, on every keystroke.
          console.log('[UI thread] typed:', value);
        }}
      />
    </Host>
  );
}

Note: you'll need react-native-reanimated and react-native-worklets installed in your project for this to work.

How this actually works

Two pieces make this possible:

useNativeState creates an ObservableState - a SharedObject that lives in native code and gets observed by both SwiftUI and Compose. On iOS, it maps to an ObservableObject. On Android, it's a MutableState. Both platforms watch this state and re-render when it changes.

Worklet callbacks like onTextChange run directly on the UI thread when the native view fires its event. No bridge crossing required.

Put them together: each keystroke in the TextField updates the shared text state, executes your worklet, and triggers SwiftUI and Compose to re-render. All on the UI thread, all in the same frame.

If you know SwiftUI, this pattern should click immediately. The TypeScript above translates almost directly:

struct Screen: View {
  @State var text = ""

  var body: some View {
    TextField("Type something", text: $text)
      .onChange(of: text) { _, newValue in
        print("[UI thread] typed:", newValue)
      }
  }
}

useNativeState acts like @State, text={text} works like TextField(text: $text), and the worklet onTextChange behaves like .onChange(of:). Compose developers will recognize the same shape with mutableStateOf and onValueChange.

Input masking without flicker

The immediate win here is input masking that actually works. Since the worklet can modify text.value in the same frame as the keystroke, users never see the unmasked character. No async delays, no visible corrections.

Take this credit card field that formats 4242424242424242 into 4242 4242 4242 4242 as you type:

import { Host, TextInput, useNativeState } from '@expo/ui/swift-ui';

export default function CardNumberField() {
  const value = useNativeState('');

  return (
    <Host matchContents>
      <TextInput
        value={value}
        placeholder="Card number"
        onChangeText={(value) => {
          'worklet';
          const digits = value.replace(/\\D/g, '').slice(0, 16);
          const masked = digits.replace(/(.{4})/g, '$1 ').trim();
          text.value = masked;
        }}
      />
    </Host>
  );
}

The formatting happens instantly on the UI thread. You can use this pattern for phone numbers, dates, currency formatting, or any scenario where display text needs to differ from raw input.

Beyond input masking

Worklet integration does more than solve input problems. It gives Expo UI a path to expose synchronous alternatives alongside existing async APIs. You pick the approach that fits your interaction needs.

This same native state + worklet pattern opens up much more of SwiftUI and Compose's state-driven APIs for React Native. Input masking is just the beginning.

Getting started

Worklet support works in both @expo/ui/swift-ui and @expo/ui/jetpack-compose. It shipped in SDK 56. TextInput supports sync callbacks now, with more form controls coming in future releases.

This post is based on content from the Expo blog. Follow @expo for more React Native content.

How to upgrade to Expo SDK 56

Dan — Sat, 23 May 2026 13:32:39 +0000

Originally published on expo.dev/blog
By Keith Kurak

Expo SDK 56 is here, with support for React Native 0.85, and React 19.2. Android API level 36 and Xcode 26.4 and higher are supported. Also unchanged are the minimum supported operating systems: SDK 56 can build apps for Android 7+ and iOS 16.4 and higher. Check out the changelog to get a full picture of all that’s included. And here’s a short highlight video:

Each SDK undergoes extensive testing and a beta test period, where the Expo team and the community collaborate to find issues that might stand in the way of a fast and smooth upgrade for others. A lot of Expo engineers maintain our own apps and try to upgrade those as soon as the beta is out.

Nonetheless, there’s practically infinite possibilities out there. Every app is unique, and has its own complexities that will need to be accounted for when upgrading. Therefore, we wanted to highlight some specific key changes that may affect your upgrade to SDK 56, as well as some evergreen advice when it comes to upgrading to the latest Expo SDK.

Key things to know as you upgrade to SDK 56

Power your SDK upgrade with Claude Code

At Expo, we use Claude Code in our day-to-day work. Based on our experiences, we’ve published some skills to help with common tasks within Expo apps in the expo/skills library. One of these skills is for upgrading to the latest Expo SDK version. In addition to the basics like updating package versions, it handles things like breaking changes, cleaning up outdated configurations, and more.

Within Claude Code on your terminal, run

/plugin marketplace add expo/skills

to add the skills marketplace to Claude, and then

/plugin install expo

After restarting Claude, you can ask it in plain language to upgrade your SDK. If it’s installed correctly, you should see Claude reference the skill as it gets started:

You can also import Expo skills into other agents via

bunx skills add expo/skills

As always, do your work on a separate branch, and review your code before merge and deploy. LLMs are amazing, but Claude and the Expo upgrade skill can’t be aware of every possible scenario. Human developers are a vital part of this workflow!

Faster native builds

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

For Android, 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.

Expo Go update

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 will update the SDK 56 changelog when we have more news to share. For more information, you can refer to “Expo Go and the App Store in May 2026.”

The Expo Go app is our tool for getting started quickly, it's an educational tool to help you learn to build on mobile. We encourage you to take advantage of this transition period to migrate your project to using a development build, which provides you with everything that you need to build an app that you ship to stores.

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.

Hermes bytecode diffing for updates is enabled by default

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.

Inline Expo Modules

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

Tips for upgrading your Expo SDK

We have written up detailed advice for troubleshooting issues found during an upgrade. This includes considerations for both before and during your upgrade, with a list of suggestions, starting with the quickest/easiest to try. We recommend reading the entire guide, but we wanted to highlight a few key items in brief here:

Use the upgrade skill!

It’s so nice, we’ll say it twice: Add the expo/skills library to your preferred LLM and let it do the upgrade for you.

Troubleshoot with Expo MCP

Expo MCP now includes more tools to help you troubleshoot your upgrade alongside Claude Code, Codex, Cursor, and others. If one of your EAS builds fails, use the build_logs tool to pull down the build logs for analysis with AI. If you install the expo-mcp package, you can use the collect_app_logs tool to pull native logcat / macOS console logs from your emulator/simulator.

Check the changelog

Most SDK releases will have a list of known breaking changes, or notable changes where you may need to tweak configuration for a scenario specific to your app. The best time to read the changelog and breaking changes is before you upgrade, so you can make those tweaks before you test, but the next best time to read it is after you upgrade, particularly if you see a compilation error or crash.

Using development builds over Expo Go

Upgrades are best taken when you don’t feel rushed to complete them. As Expo Go automatically upgraded to the latest version after the SDK release on your phone, you may have noticed that your app no longer worked in Expo Go, and felt that you needed to upgrade right away in order to keep working on features.

Development builds help reduce the temperature, giving you time and space to take on an upgrade while not interrupting ongoing feature work. A development build works a lot like Expo Go, allowing you to scan a QR code to work on your code locally without rebuilding. But it’s your own app, so it will not get upgraded when a new version of Expo Go is released.

If you still feel that you need to use Expo Go, know that you don’t necessarily have to use the latest version on the Play and App Stores. You can go to https://expo.dev/go and download previous versions for use on Android devices and iOS simulators. Unfortunately, due to App Store restrictions, this does not work on iOS devices.

Still, another reason to migrate to a development build is because Expo Go is quite limited in how it can replicate your production app, leading to issues where it works in Expo Go but not when you build your production app. Expo Go can run your JavaScript, but it cannot apply most of your app.json / app.config.js configuration, because that would require modifying native code. In short, Expo Go can’t contain nearly everything that’s unique and special about your app. Development builds can. There's plenty of headroom in the Free plan to make some development builds, or you can build locally npx expo run:android or npx expo run:ios.

New Architecture advice

Expo SDK 54 was the last SDK to support the Old Architecture. SDK 55+ / React Native 0.83+ only support New Architecture. Therefore, if you haven’t upgraded to the New Architecture yet, now is definitely the time! A number of the latest versions of major packages, such as react-native-reanimated v4 and @shopify/flash-list v4, only support New Architecture.

Avoid upgrading both your Expo SDK and adopting New Architecture at the same time. This makes it more difficult to isolate any issues. Compared to upgrading your Expo SDK, adopting New Architecture is the bigger change, so any issues are likely related to that- but it will be hard to tell if you upgrade to both at the same time.

We recommend first upgrading to the New Architecture on SDK 54 and then creating a development build. Test that, using our New Architecture troubleshooting guide to help if you run into any issues. After you’ve verified things are working just by upgrading to New Architecture, upgrade to SDK 56 and make a new development build. Now, you’ll just be testing your SDK 56 upgrade in isolation.

Check the troubleshooting guides

We have a landing page of our most popular troubleshooting guides that you can browse depending on your issue. If your issue is an error when building, you’ll want to take different steps compared to a crash or performance issue. Even if you don’t fully get to the root cause, using a tool like ADB Logcat or macOS console to find a native error that the operating system reports from a crash can be very helpful as you engage in further troubleshooting or ask others for help.

Reach out if you need a hand!

We appreciate your bug reports and feedback! The best way to surface an issue is and will always be a Github issue with a minimal reproduction, where you send us a link to a Github repo based on the default project template created with npx create-expo-app , plus just enough code to reproduce the issue.

A minimal reproduction ensures that our team can see exactly what you’re seeing and gives us a way to test that our fix will work for you. Even if that seems like a lot to do, often spending 15 or 30 minutes trying to make a minimal reproduction is more effective than hours spent debugging on your actual app, where there are a lot of moving pieces and it’s more difficult to isolate issues. AI tools like Claude can even help make the minimal reproduction for you.

We also understand the value in discussing an issue in the moment, even before you’re ready to try to reproduce it. Other developers may be experiencing the same thing and already have an answer. Discussions about issues on Discord, Reddit, Bluesky and elsewhere can result in a sort of collaborative virtual rubberducking where we find the answer together while talking through it.

We encourage you to post screenshots or videos of the issues you’re facing, or at least descriptions of what exactly you’re seeing, what platforms are affected, etc. so we can see what is broken and help the community think through how to isolate that issue and find a solution. If you have detailed feedback about the upgrade process that doesn’t fit neatly into a minimal reproduction of a single issue, we’d love to hear about it, as well. Besides social forums, we always have someone checking on the messages received from our support page.

Happy upgrading and we hope you love SDK 56!

Expo SDK 56

Dan — Thu, 21 May 2026 18:21:13 +0000

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.

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.

ASO Skills: ASO in Your AI Workflow

Dan — Tue, 19 May 2026 22:59:45 +0000

Originally published on expo.dev/blog
By Erencan Arica

A few years ago, launching a React Native app meant weeks of setup configuring Xcode, managing signing certificates, wrestling with Android Gradle configs, and cobbling together a CI/CD pipeline from scratch. Today, with Expo, a solo developer can go from idea to a production-ready native app in a single afternoon. It's a dream. And that's before we even mention LLMs.

But speed creates a new problem: when shipping is fast, the bottleneck shifts. It's no longer building the app, it's getting it found.

That's where App Store Optimization comes in.

Why shipping fast made App Store discovery harder

Here's the tension: Expo makes is easier for everyone to ship an app and now the App Store has over 2 million apps competing for attention. Paid acquisition costs have risen over 30% year-over-year, making organic discovery more important than ever.

And here's the stat that changes everything: 65–70% of app downloads still come from App Store search.

Not ads. Not social media. Not influencers. Search.

If your app doesn't rank for the right keywords, most of your potential users will never see it regardless of how polished the product is. Great apps with poor store listings get buried. Mediocre apps with excellent ASO get downloaded.

What is App Store Optimization (ASO)?

Before going deeper, I want to explain what App Store Optimization (ASO) actually means. ASO is the practice of optimizing your app to rank higher in App Store or Play Store search results tp attract more users to install.

Think of it as SEO, but for the App Store. The principles are similar: understand what your users are searching for, then make sure your listing reflects it clearly and accurately.

There are key elements of ASO:

Title (30 chars): Your strongest ranking signal. A core keyword in the title can lift rankings by up to 10%.
Subtitle (30 chars, iOS): A secondary ranking signal. Complement your title with different keywords, both fields are indexed together.
Keyword Field (100 chars, iOS): Hidden from users, fully indexed by Apple. No spaces after commas, no duplicates from your title, no filler words.
Screenshots: No longer just a conversion tool. With Apple's semantic search, the text in your screenshots is indexed and affects your ranking directly. Users decide in ~7 seconds, so lead with your value prop, use keyword-rich captions, and show real UI.
Ratings & Reviews: A direct ranking factor. Prompt at the right moment, after a user achieves something, not on first launch.
Localization: Each locale gets its own keyword field, title, and screenshots. Most developers only do English and leave massive markets untapped.

ASO is not a one-time task. Algorithms evolve, competitors iterate, new keywords emerge. The best teams treat it as an ongoing practice, not a launch checklist. It’s best to revisit your listings each month. That’s why I came up with open-source ASO agent skills with real-time data.

ASO Skills: bringing App Store Optimization into your AI workflow

This is the problem I wanted to solve when I built ASO Skills, an open-source collection of AI agent skills for App Store Optimization and mobile app marketing.

The idea is simple: package ASO expertise directly into the tools you already use.

Whether you're working in Cursor, Claude Code, Codex or any Agent Skills-compatible environment, you can ask your AI assistant to run a full ASO audit, research keywords, analyze competitors, and generate optimized metadata, and get structured, actionable results backed by real App Store data.

The library ships with 20+ skills across three areas. But what makes them powerful isn't the individual skills, it's how they work together. Each skill is aware of the others, so instead of running isolated commands, you get a natural, guided workflow:

aso-audit
   → flags weak spots in your listing
   → recommends keyword-research for gaps

keyword-research
   → finds high-opportunity keywords for your category
   → feeds into metadata-optimization

metadata-optimization
   → generates your title, subtitle, and keyword field
   → ready to ship

You start with an audit, follow the recommendations, and end with a fully optimized listing, all in one conversation with your AI assistant. No dashboards, no spreadsheets, no context switching.

Build, ship, and optimize your app in one workflow

The Expo development workflow is fast, automated, and increasingly AI-native. You can build a polished app, run tests, and ship to production without leaving your editor.

ASO Skills brings the same philosophy to your marketing workflow. You shouldn't have to context-switch to a separate dashboard, copy-paste keywords into a spreadsheet, or hire a consultant to understand why your app isn't ranking.

Ask your AI. Get a structured audit. Fix the highest-impact issues. Ship the update with Expo’s services.

The entire loop - build, ship, optimize, iterate - now lives in one environment. Expo already removed the friction from shipping. I hope these skills remove the friction from being found.

Here is the repo: github.com/Eronred/aso-skills

How to keep your OTA updates lean and fast

Dan — Sun, 17 May 2026 16:32:20 +0000

Originally published on expo.dev/blog by Jacob Clausen.

Have you ever shipped a critical fix to your entire user base within minutes of merging the PR - a straight highway from your fix to your users’ fingertips, no bureaucracy, no interruption to the user experience? That feeling never gets old.

EAS Update makes this possible, and once you’ve experienced it, it’s hard to imagine working without it. But publishing the fix is only half the story. Your users don’t benefit until it’s running on their devices. The faster that download completes, the sooner your fix is in their hands. And the leaner your updates are, the better the experience gets for everyone. Faster downloads, lower costs, and a smoother ride as your team and user base grow. In this guide, we’ll walk through how to keep your updates small, ship them with confidence, and get the most out of every push.

EAS Update pricing recap

To get the most out of EAS Update, it helps to understand two concepts that shape how your updates are delivered and billed: Monthly Active Users (MAUs) and bandwidth. Knowing how they work, and the things you can do to keep your updates lean, means faster downloads for your users and lower costs for you. This blog post assumes you’re already familiar with what EAS Update is and what scenarios it’s useful for.

Monthly Active Users (MAUs)

A Monthly Active User (MAU) is a unique user who downloads at least one update via EAS Update within a single billing period. No matter how many updates they download that month, they still count as one MAU. And if a user checks for updates but nothing new is available (so no download happens), they’re not counted at all.

Uninstalling and reinstalling the app will count as a separate MAU the next time they download an update. Similarly, the same person on two different devices would count as two MAUs. These edge cases probably won’t dramatically change your numbers, but they’re good to be aware of if your actual MAU count doesn't exactly match Play and App Store counts or metrics that consider more context about the unique identities of your users.

Bandwidth

While every update a user downloads consumes bandwidth, the quotas on each plan are generous, and most teams stay comfortably within their plan's allocation. Actual bandwidth usage tends to be much lower than you might expect, thanks to factors like compression.

The size of that download depends on what changed. For example, if only your JavaScript was updated, that’s all the user downloads. Assets already on the device from the original build (or from a previous update) aren’t re-downloaded.

That number is often smaller than you’d think: if you publish three updates in a week and a user only opens your app once that week, they download one update - not three. Only the latest update is downloaded, and the rest are skipped. From both a speed and bandwidth perspective, this is great - your users aren’t downloading more than they need to, which means updates are delivered faster and you’re only paying for what’s actually being used.

That said, keeping your updates lean is still worth doing for a bunch of reasons beyond billing: faster downloads, less data usage for your users, and a snappier experience all around. More about this later.

One thing we’re really excited about: with SDK 55, you can opt in to Hermes bytecode diffing (currently in beta, please check it out!). Instead of downloading a full JavaScript bundle, the client applies a binary diff to what’s already installed. This can reduce download sizes significantly, meaning your users get updates faster and you can ship more frequently. It’s one of the ways we’re actively working to make updates both cheaper to deliver and better for your users.

Why smaller updates matter

The smaller your updates are, the faster they download for your users - and the less bandwidth each update consumes, both for your EAS Update usage and for your users on cellular or limited data plans. Smaller bundles also mean faster builds, and when your app loads an update on launch, a leaner bundle means a snappier startup. And if your bundle gets large enough, you might even notice it during development - live reload can start to feel slow when it has to process a big bundle on every change. Here are some techniques worth knowing about.

Optimize your assets

Images can add up quickly in your update size, so it’s worth making sure they're optimized before you ship. Compressing your images where possible can make a meaningful difference - often with little to no visible quality loss. The smaller your images, the faster your updates download and the less data your users consume.

Let your assets be assets

When an image is a proper asset file, it gets downloaded once (either through a build or an update) and stays on the device. Future updates skip it entirely if it hasn’t changed. But when assets are inlined in your JavaScript (like for example base64-encoded images), they’re part of the bundle itself, so they come along for the ride on every update.

For images that change frequently or live outside your bundle entirely, serving them from a CDN paired with expo-image is worth considering. Its default caching policy persists images to disk on first load, so they behave just like bundled assets after that (downloaded once, reused across app restarts) without adding any weight to your updates.

Choose which assets go into your updates

Not every asset in your project needs to be delivered through updates. With asset selection, you can specify exactly which assets should be included using file patterns in your app config. Everything else stays in the native build and never gets downloaded from the update server.

For example, if only the images in your app/images directory change between releases, you can limit your updates to just those:

{
  "expo": {
    "updates": {
      "assetPatternsToBeBundled": [
        "app/images/**/*.png"
      ]
    }
  }
}

Once you’ve configured your patterns, run npx expo-updates assets:verify before publishing. This ensures that all required assets will be included when you publish an update - assets that fall through the cracks won't be available, which can cause unexpected behavior or crashes. Check out the docs for more details.

Submit to the app stores regularly

When you submit a new build to the app stores, it includes all your latest assets. That means any OTA updates you publish after that only need to include what’s changed since the build, so users download less. If you’ve recently added large or multiple new assets, shipping a new build is a good way to keep your next updates lean.

One approach that works well is pairing a regular binary release cadence (say, monthly) with OTA updates for changes in between. Your users get improvements more frequently, and each new binary resets the asset baseline for your subsequent updates.

Keep your JavaScript bundle in check

Your JavaScript bundle is part of every update you publish. Tools like Expo Atlas give you a visual breakdown of your bundle, showing exactly how much space each dependency takes up. It can be a real eye-opener - you might discover a library you imported for a single utility function is pulling in way more than you expected, or spot a dependency you stopped using but never removed.

You can try it right now with your local dev server. Start your app with Atlas enabled:

EXPO_ATLAS=true npx expo start

Then press shift + m in the terminal running the dev server to open the dev tools plugin menu and launch Atlas.

Shipping updates efficiently

So far we’ve covered how to keep your updates lean. But the way you ship updates matters too. Rollouts give you more control over how updates reach your users, and using updates for internal testing can save you time and build credits.

Use rollouts for production updates

When you publish an update, it’s available to your entire user base by default. Every update your users download counts toward your bandwidth usage, so rollouts are a natural way to be efficient: start with a small group, make sure everything looks good, and then roll it out to everyone.

Use updates for internal testing and PR previews

During development, getting changes in front of your team for review often means creating a new build. But for changes that don’t involve native code, an OTA update does the same job - and it takes only seconds. Your team can preview changes directly on a development build they already have installed, or even from a pull request preview that’s generated automatically.

The more of your review and iteration cycle that happens through updates rather than builds, the less time you spend waiting around before anyone can look at a change. Your team can have the latest version on their device in seconds, which means the feedback loop opens up much earlier in the process. That adds up fast when you’re iterating on a feature, and you’re saving build credits along the way. And since it’s just your team downloading these updates, the MAU and bandwidth cost is practically zero, making it one of the best value-for-effort wins on your plan.

Keeping track of your usage

Everything we’ve covered so far (keeping updates lean, using rollouts, leveraging updates for internal testing) all contributes to getting more value out of your EAS Update plan. But it’s also nice to know where you can see how things are going.

Monitor your usage in the dashboard

Expo provides a usage overview on your account’s Billing and Usage pages. There you’ll find a summary of your EAS Update usage: how many MAUs have downloaded updates and how much bandwidth has been consumed during the current billing cycle (or given time period). It’s a handy way to stay informed, especially if you’re curious how your numbers look after a big release.

Use the pricing calculator to find the right plan

If you’re trying to figure out which subscription plan fits your needs, the pricing calculator on the Expo website can help. Adjust the sliders for your expected MAU count, builds, and CI/CD minutes, and it’ll recommend a plan - and if your numbers go beyond what’s included in that plan, it’ll show you the estimated cost of that extra usage too.

Pick the plan that fits today

You don’t need to have everything figured out before choosing a plan. Start with what fits your current needs - you won’t hit a wall if your app grows faster than expected. Every plan scales naturally with your usage, and you can move between plans as your needs change. Expo’s pricing is designed to grow with you, not get in the way. EAS Update is available on every plan, including the free plan, so you can try it out without any commitment.

Wrap-up

At the end of the day, EAS Update gives you a pretty sweet deal: ship updates to your users in seconds, iterate faster with your team, and scale at your own pace. Leaner updates, rollouts, and a few of the techniques we covered are all it takes to deliver a faster experience for your users while getting more value out of your plan.

Ready to get started? Set up EAS Update in your project - it only takes a few minutes to set up, and you can start shipping updates right away. If you want to dive deeper into any of the topics we covered, the EAS Update docs are a great next step. We’d love to hear about your success story with EAS Update too!

Introducing EAS Hosting: Simplified deployment for modern React apps

Expo Team — Tue, 14 Jan 2025 15:40:31 +0000

From weather apps, and commerce websites, to AI-powered chat apps, most modern applications today need reliable servers. That's why today we're introducing EAS Hosting for instantly deploying and scaling universal API routes, React websites, and more!

The Challenge of Universal App Deployment

Many massive companies such as Netflix, Meta, and Apple use server-driven UI in their native apps. But building a server-driven application is extremely challenging and simply out of reach for most developers. Our goal with Expo Router has been to solve this problem and enable anyone to build and scale world-class server-driven apps for Android, iOS, and web using the same codebase.

To this end, we've introduced API Routes that can be used to create server endpoints for your app, secure environment variables, and static generation for web pages, all building toward universal React Server Components. While all these features work great on a local dev server, deployment has become more challenging.

There are many full-stack problems to consider when building a modern application. We've historically recommended deploying Expo websites and universal API routes to traditional hosting services that are focused only on websites. But hosting services for websites traditionally don’t integrate with the problems native apps face.

New versions of your servers may need to be deployed while new versions of your native app are being published to app stores.
Different versions of your native app may need to have their requests routed to different versions of your server.
Observability of servers for critical metrics, such as feature adoption by platform, becomes more important for Expo native apps.

With EAS Hosting, in conjunction with EAS Workflows, we’re providing an end-to-end deployment solution that just works across all platforms, and stays working as you scale.

How to Get Started with EAS Hosting

First, ensure you’re using the latest version of EAS CLI:

npm i -g eas-cli

Then simply bundle your app with Expo CLI, deploy your website and server code worldwide with a single EAS command, and get a preview URL immediately:

npx expo export -p web
eas deploy

That's it! Your website and API routes are now live with a beautiful .expo.app URL that you can share with anyone. (For an example Expo web deployment, visit: https://bacon.expo.app)

Add environment variables to your .env file, and these will securely reside on the server-side for use in API routes and React Server Functions, keeping them out of your client code.

By visiting the EAS dashboard, you can monitor your deployments and see helpful telemetry. Server errors are automatically aggregated and can be linked to for triaging!

Here's a comprehensive video demonstration of EAS Hosting that covers deployment, assigning aliases, using API routes, looking up request logs, managing environment variables, and automating deployments with Workflows:

Fingerprint your native runtime with @expo/fingerprint

Expo Team — Tue, 06 Feb 2024 23:47:00 +0000

At Expo, we’re always looking to find systematic solutions to problems that developers encounter when building apps with React Native. There’s a set of time-consuming questions related to the native project runtime that comes up again and again, and up until now, there hasn’t been a good systematic approach to answering them.

The questions go something like this:

Does a pull request include native code changes and need to initiate a new build for testing?
Is my update compatible with the runtime in my production app? Or will it crash the app?
Does a project require a development build, or can I experiment with it in Expo Go?

While these issues may seem quite different initially, on closer examination they all come down to one key problem: "Given a project, can we deterministically generate a hash, identity, or fingerprint that represents its unique native characteristics?"

Meet @expo/fingerprint

Now, by running npx @expo/fingerprint@latest /path/to/yourProject, you can get a full picture of your project's native setup. @expo/fingerprint also comes with an API, so you can integrate this tool programmatically into your own projects.

We think this is a massive milestone for the whole React Native ecosystem and it's already unlocking some super interesting use cases that are not immediately obvious. Krzysztof Magiera is using it to make startup of his RN IDE plugin for vscode much faster.

Here’s an example of what the fingerprint looks like:

{
  "sources": [
    {
      "type": "file",
      "filePath": "app.json",
      "reasons": ["expoConfig"],
      "hash": "378083de0c6e6bb6caf8fb72df658b0b26fb29ef"
    },
    {
      "type": "file",
      "filePath": "eas.json",
      "reasons": ["easBuild"],
      "hash": "f723802b6ea916d1a6c4767b2299cc81ddb22eb4"
    },
    {
      "type": "dir",
      "filePath": "node_modules/expo",
      "reasons": ["expoAutolinkingIos", "expoAutolinkingAndroid", "bareRncliAutolinking"],
      "hash": "1faee4057fa943300905750b51c3b0cbf05f4b0d"
    }
  ],
  "hash": "bf8a3b08935f056270b1688333b02f1ef5fa25bf"
}

Developers can represent the entire native state of their project with a single, succinct hash value, which is immensely valuable for easily detecting native changes. But there are several other important considerations that we accounted for in order to maximize the usefulness in various use cases:

Speed: we’ve tried to make this tool as fast as possible so you can run it often, and we’ll continue to push on that to make it even faster.
Precision: we should only consider aspects of the project that are actually relevant (it can’t just be a hash of the entire project and all of the .DS_Store and .swp files or the value would not be useful).
Support for diffing: You should be able to compare fingerprints to determine what’s different between them.
Customizability: The API exposes some options that you can use to customize for your workflows — most notably, you can either add extra files to hashing or exclude files. We also read the .fingerprintignore file from your project root, which works similarly to .gitignore.

Try out @expo/fingerprint 🪄

@expo/fingerprint fully supports projects made with Expo CLI and also works with any bare React Native apps, whether they use Expo tools or not. Follow these steps to see it in action:

Generate a fingerprint JSON file: run npx @expo/fingerprint@latest /path/to/yourProject > fingerprint.json
Change your native runtime: one easy way to do this is to install an npm package with native dependencies, for example: npx expo install expo-camera or npm install react-native-vision-camera.
Diff the fingerprint: run npx @expo/fingerprint@latest /path/to/yourProject fingerprint.json. Notice that it will identify what changed, for example if you installed expo-camera, you will see something like this:

[
  {
    "type": "dir",
    "filePath": "../../node_modules/expo-camera/android",
    "reasons": [
      "expoAutolinkingAndroid"
    ],
    "hash": "7682b28ed4ef8356faa5d9ad5b71e76e53198375"
  },
  {
    "type": "dir",
    "filePath": "../../node_modules/expo-camera/ios",
    "reasons": [
      "expoAutolinkingIos"
    ],
    "hash": "a80c2b1abb73157b772a8d0a351920465894bb0d"
  },
    // the rest is redacted for brevity
]

You can use this API programmatically with the Fingerprint.diffFingerprintChangesAsync(fingerprint, projectRoot) function.

What’s next: collect feedback and refine workflows

We think @expo/fingerprint is really going to help with automating decisions like when you can safely send out updates and analyzing your team's pull-requests to rebuild the native app only when it’s really needed.

Even though this is the first time we’re publicly talking about @expo/fingerprint, we’ve already had some early adopters who have opened PRs / issues to help make the tool better accommodate their projects.

We also know that the tool’s built-in opinions might not be perfect for every project. We want help from the community to test this tool thoroughly, and one way that we’ve made it very easy to do so is with our GitHub Actions integration, which is available now! (Blog post on github actions coming soon.)

Using @expo/fingerprint with EAS

In the future, we plan to build first-class integration for @expo/fingerprint into EAS services. You can use @expo/fingerprint in your EAS projects today by generating your fingerprint with the CLI and populating your runtimeVersion field with it, then comparing that value with the value generated at the time when you would like to do an update or build. If you use GitHub Actions to kick off your builds and updates, then may also want to use the GitHub Actions integration!

Expo SDK 50 Release 🚀

Expo Team — Thu, 18 Jan 2024 23:38:27 +0000

Today we’re announcing the release of Expo SDK 50.

SDK 50 is a very chunky and ambitious release that includes React Native 0.73. Thank you to all the contributors and to everyone who helped with beta testing.

Learn more in the full article on the Expo Changelog.

And please join our live stream on January 31st at 10:30am PT for a walkthrough of what’s new.

Introducing EAS

Expo Team — Wed, 10 Nov 2021 22:23:13 +0000

EAS stands for Expo Application Services, the fastest way to get your Expo app from development to the app stores.

Over the last few months, we've been previewing two new services: EAS Build and EAS Submit, the first services available from Expo Application Services (EAS).

Today, we're happy to announce that EAS is moving out of preview and into general availability!

What is EAS?

Expo is our open-source project: it will always be both open source and free - forever!

Expo Application Services (EAS) are our hosted cloud services built for both Expo and React Native. With EAS Build and Submit, we make it faster and easier for you to get your app from development into the app stores.

To learn more about EAS, head over to expo.dev/eas or check out our docs.

EAS Build and Submit

EAS Build takes everything good about the classic Expo build service (expo build:[android|ios]) and leaves all of its limitations behind. EAS Build raises the ceiling on what's possible with Expo managed workflow apps by adding support for custom native code and for building "Development clients" in the cloud. The service works great with both managed and bare Expo apps, or any React Native app you throw at it. You can also run it locally or on your own infrastructure.

You can build your app with EAS Build and automatically submit to app stores with EAS Submit in minutes or less, thanks to automatically managed app signing credentials, automatic submissions, and defaults that just work for most Expo and React Native apps.

Internal distribution makes it easy to share test builds with colleagues and friends using ad hoc provisioning or enterprise provisioning on iOS and APK side-loading on Android.

Everything works great for your entire team out of the box and can be integrated into your existing CI/CD workflows.

New EAS plans

With our EAS General Availability release, we are introducing three new plans: Free, Production, and Enterprise.

All our EAS services are now available under the Free plan, which is a great option for pre-revenue startups and proofs-of-concept, as well as hobby and student projects.

The Production plan is for any commercial app in production generating more than $1,500 per month in revenue, or any team using EAS in a serious way. With the Production plan, you get priority for your builds, additional build concurrencies, and access to add-ons as well as to the Expo Professionals forum. The Production plan is $99/month.

The Enterprise plan is for teams that want to work closely with Expo on their apps. Enterprise plans include more of everything in the Production plan and gives access to add-on features like SLAs and dedicated support.

Folks currently on the EAS Priority plan will be able to stay on that plan until they're ready to switch!

Enterprise support add-on

We often get requests for additional levels of support and are happy to announce our Enterprise Support plan that's now available as an add-on to our Enterprise plan.

With Enterprise Support you'll get direct access to the Expo team for questions and troubleshooting via a dedicated Slack channel. To learn more, check out our Enterprise Support page.

Get started with EAS - free!

All Expo accounts get access to the free EAS plan, so everyone can now try out EAS Build and Submit.

To learn more, look at creating your first build.

Thank you!

We want to extend a huge thank you to all the developers who participated in the preview and provided feedback for EAS Build and Submit. That feedback was a tremendous resource whether it was helping to track down a tricky bug, uncovering new use cases, or suggesting new improvements and functionality.

In total, developers participating in the EAS preview period built over 100,000 successful builds of their apps - with over 80,000 app store submissions! Hats off to all our preview developers!

Of course, just because we're out of the preview period, that doesn't mean we're done! We'll continue to add great new features and services - so please stay tuned and keep that feedback coming in!

Expo SDK 41

Expo Team — Fri, 23 Apr 2021 23:02:17 +0000

Today we're announcing the release of Expo SDK 41. SDK 41 includes React Native 0.63, the same version as in SDK 40. Thank you to everyone that [helped with beta testing[(https://blog.expo.io/expo-sdk-41-beta-is-now-available-958edcd78991). (Curious why we didn't include the recently released React Native 0.64? Learn more.)

⚡️ Highlights

Android apps now target Android R (11 / SDK 30). This comes with some significant changes for location permissions, media library (related to StorageAccessFramework), and constants. Please note that these changes also impact SDK <= 40 projects in Expo Go, but they will not impact SDK <= 40 standalone apps. Refer to expo.fyi/android-r for more information.
The recommended version of react-native-reanimated has been updated to v2. If you would like to use v2 features in your app, you need to add the Reanimated v2 Babel plugin. You can continue to use v1 features (eg: those used by React Navigation v5) without adding the new Babel plugin. Please note that if you use the new features from v2, you will not be able to use remote JS debugging in your app! If you use v2 APIs, JS debugging is only possible using Flipper and Hermes, which are not yet fully supported in the managed workflow. (We plan to investigate integrating Hermes during the next SDK cycle, but we don't currently expect to have it ready for SDK 42.)
lottie-react-native has been updated to the latest version (3.5.0). Your existing animations should continue to work as before, but if you encounter any issues please file an issue and share the animation file.
The new version of react-native-screens (v3) "enables screens" by default. If you encounter any related issues, you can report the issue and opt out with enableScreens(false). Be sure to update to the latest v4 patch release of React Navigation if you use v4.
Improvements were made across the SDK to ensure compatibility with EAS Build. A big part of this SDK has been making the necessary underlying changes to support EAS Build for managed projects. You can now use EAS Build with Expo managed apps to reduce the size of your standalone apps by up to 10x! Learn more about the latest EAS Build updates.
The expo package is now 93% smaller in production and better than ever. We've simplified the experience so the .expo extension is no longer needed (and so we removed it), and neither is the --target bare|managed flag - updates will run in either context provided the native runtime is compatible. We've improved consistency across the managed and bare workflow, removed legacy code, and improved tree-shaking on the package using @expo/metro-config.
To see the full list of new features and fixes, refer to the changelog!

🏡 Expo Go

We changed sign in to use expo-web-browser so we can leverage our existing web auth flow with two-factor-authentication.
You can now see teams and organizations that you are a part of in the Profile tab, and their associated projects show up in your recent projects below.

Notice the "Accounts & Organizations" section and the shared "Recent Projects" list below it.

🌐 Expo CLI

Integrated Developer Tools: Open the developer menu, inspect elements, and monitor performance all from the CLI. Just run expo start then press "m" to toggle the dev menu, and "shift+M" to toggle the performance monitor or element inspector across native apps.

It was either a heavily compressed but still 7mb gif or a YouTube video, so we went for the YouTube video.

Force Reloading: Shaking your devices every few minutes can get exhausting! Now you can reload connected phones, tablets, simulators, and browsers all by pressing "r" in the Terminal UI. This works across iOS, Android, web, and on physical devices.

Automatic TypeScript setup: Setting up TypeScript can be a pain, so we've completely automated it! Just create a blank tsconfig.json and run expo start, we'll take care of the rest! Learn more: "TypeScript" in the Expo docs.

Vastly better errors: No one likes errors - that's why in SDK 41 we've refined them to be as concise, and useful as possible! We only surface the most relevant stack traces and point to exactly where the error or warning is. We've also improved source maps, and muted generated code traces.

Debug your config: The new expo config command enables you to view the evaluated results of app.config.js or app.json. You can use expo config --type public to see the app manifest used in expo publish.
Better interactions with Apple Store Connect from your terminal: Faster, smarter authentication, better error handling, and - for the first time ever - get full insight into complex issues right from the console. Where other tools 401, Expo CLI gives you links to resolve issues in seconds. Need to update your payment or accept a contract? Resolve in a couple clicks, and get back to developing incredible (or at least "good") apps!

A terminal window showing information about a rejected request from App Store Connect due to an expired Developer Program membership.

The --config is flag deprecated. We suggest using app.config.js instead. The --config flag will continue to be supported for existing use cases for the foreseeable future, but it will not be supported in some situations in bare workflow projects, and it will also not be supported on EAS Build. Learn more: Migrating away from --config in Expo CLI.
The --target flag is deprecated for SDK 41+. This was used to provide slightly different behavior when in a managed or bare app environment, but it ended up being tricky to use because updates published with the bare target could not run in Expo Go, and updates published with the managed target could not run in a bare app. We now do any necessary adjustments to accommodate the environment at runtime, so an update bundle will work in either context, provided that the native runtime is compatible with the update.
Versioned Metro Config: Rather than adding @expo/metro-config to your package.json, you can now import it through the expo package with the vendored expo/metro-config import. This ensures that your project is always using a compatible version of the package. Learn More: Customizing Metro.
Introducing Config Plugins (beta): Config plugins are an important step towards making it possible for library authors to make their native modules part of the Expo ecosystem. This system is in beta, with a more stable release planned for SDK 42. Learn more: Config Plugins.

🏗 Deprecations, renamings, and removals

Deprecated globals have been removed from the expo package.As a result, expo-linear-gradient, expo-linking, expo-location, expo-permissions, and expo-sqlite are no longer automatically installed in every project by default as dependencies of expo. If you were depending on global.expo.LinearGradient or similar, please install the respective package and import the API from there instead, eg: import { LinearGradient } from 'expo-linear-gradient';. Refer to expo.fyi/deprecated-globals for more information.
Files with the .expo.* extension (eg: MyComponent.expo.js) are no longer recognized as source files. If your project source code or dependencies include any files with the .expo.* extension, expo-cli will let you know when you upgrade. Refer to expo.fyi/expo-extension-migration for more information.

We thought the .expo file extension was neat but it ended up not being necessary or particularly useful, and simplicity wins over neat things.

expo-permissions has been deprecated in favor of module-specific permissions methods. You should migrate from using Permissions.askAsync and Permissions.getAsync to the permissions methods exported by modules that require the permissions. For example: you should replace calls to Permissions.askAsync(Permissions.CAMERA) with Camera.requestPermissionsAsync(). There shouldn't be two ways to do an identical thing in a single SDK, and so we picked our preferred approach and are consolidating around it.
@react-native-community/async-storage is now @react-native-async-storage/async-storage. AsyncStorage is next in the packages that are gradually migrating out of the @react-native-community scope on npm (more context on why this is happening available here). We will take care of switching the packages in your dependencies in package.json when you run expo upgrade, but after that you will need to either manually update your imports in your source code, or run npx expo-codemod sdk41-async-storage [your-source-directory] to update it automatically. Along with this superficial change in package names comes a fix for an issue that occurs when ejecting your project; more information in this issue and these pull requests.
@expo/metro-config is now vendored by the expo package. If your metro.config.js uses @expo/metro-config, you should switch over to importing it from the expo package instead. Remove @expo/metro-config from your package.json dependencies and change your import in metro.config.js from @expo/metro-config to expo/metro-config. Learn more: Customizing Metro.
Legacy Notifications API has been removed.The legacy Notifications library (imported from the expo package) has been deprecated since SDK 38, and is now fully removed in SDK 41. If you're still relying on this package, you should upgrade to expo-notifications, which has plenty of improvements and additional features. Learn more: How to migrate from Expo's LegacyNotifications to the new expo-notifications library.
👋 iOS 10 support has been dropped - Expo SDK 41 supports iOS 11+. More information on this from our SDK 40 release notes:iOS 10 is the last version of iOS that still supports 32-bit simulator builds (x86), and to keep Expo npm packages smaller, we plan to publish only 64-bit pre-build binaries for simulators (x64 and arm64). This has been past due - the last time we dropped an iOS version was over two years ago, when we dropped support for iOS 9 in September 2018. Apple no longer reports usage statistics for iOS 10 directly, but you can get a rough idea from reading the App Store - iOS and iPadOS usage table - 6% of all devices use iOS 11 or lower at the time of writing.
🟢 Node 10 support will be dropped soon from Expo CLI. It's not that we have anything against the number 10, but Node 10 is about to be replaced by Node 12 as the Maintenance LTS release.
🧹 Dropped SDK 37; will drop SDK 38 next release. We routinely drop SDK versions that have low usage in order to reduce the number of versions we need to support. This release sees the end of life for SDK 37. As usual, your standalone apps built with SDK 37 will continue to work; however, SDK 37 projects will no longer work within the latest version of Expo Go. If you want to re-run expo build, then you'll need to upgrade from SDK 37, preferably to SDK 41 so you won't need to update again for a while (and also because each Expo version is better than the last!). Our next release is planned for June/July 2021 and, at that time, we'll be dropping support for SDK 38. If your project is running on SDK 38, consider upgrading to a newer version in the coming months.

➡️ Upgrading your app

Managed workflow

Here's how to upgrade your app to Expo SDK 41 from 40:

Update to the latest version of Expo CLI: npm i -g expo-cli. expo-cli@4.4.1 or greater is required.
Run expo upgrade in your project directory.
If you are using react-navigation v4, please be sure to update to the latest v4 patch release. This is required due to changes in the version of react-native-screens included in SDK 41.
Refer to the "Deprecations, renamings, and removals" section above for breaking changes that are most likely to impact your app.
Make sure to check the changelog for all other breaking changes!
Update the Expo app on your phones from the App Store / Google Play. expo-cliwill automatically update your apps in simulators if you delete the existing apps, or you can runexpo client:install:iosandexpo client:install:android`.
If you built a standalone app previously, remember that you'll need to create a new build in order to update the SDK version. Run expo build:ios and/or expo build:android when you are ready to do a new build for submission to stores.

Bare workflow

The Bare workflow lets you operate independently of the Expo SDK cycle, updating RN versions and versions of individual Expo packages however and whenever you want. However, if you do stick roughly to Expo SDK versions, these steps will help you to upgrade to Expo SDK 41 from 40:

Install the latest version of CocoaPods - 1.10.0 or greater is required.
Update to the latest version of Expo CLI: npm i -g expo-cli. expo-cli@4.4.1 or greater is required.
Run expo upgrade in your project directory.
Update to platform :ios, '11.0' in your Podfile.
Update compileSdkVersion and targetSdkVersion to 30 in android/build.gradle.
If you are using react-navigation v4, please be sure to update to the latest v4 patch release. This is required due to changes in the version of react-native-screens included in SDK 41.
Rebuild your native projects with npm run ios and npm run android.
Make sure to check the changelog for other breaking changes!

Expo SDK 41 beta is now available

Expo Team — Tue, 30 Mar 2021 18:23:38 +0000

Learn about the changes, how to try it out, and how to give feedback

The beta period will last approximately two weeks, and it is an opportunity for developers to ensure that the new release does not introduce any regressions for their particular system and app configurations.

SDK 41 beta includes React Native 0.63, the same version as SDK 39 and 40. The full release notes won’t be available until the final release, but you can browse the changes in the expo/expo CHANGELOG to learn more about the scope of the release and any breaking changes.

Notable changes to be aware of

@react-native-community/async-storage is now @react-native-async-storage/async-storage. You must change to the new package in SDK 41.
Files with the .expo extension (eg: MyComponent.expo.js) are no longer recognized as source files. If your project source code or dependencies include any files with the .expo. extension, expo-cli will let you know when you upgrade. Refer to expo.fyi/expo-extension-migration for more information.
iOS 10 support has been dropped — Expo SDK 41 supports iOS 11+. One of the reasons for dropping iOS 10 was to reduce the size of prebuilt binaries for Expo packages.
Node 10 support will be dropped soon from Expo CLI - it's not that we have anything against the number 10, but Node 10 is about to be replaced by Node 12 as the Maintenance LTS release.
Deprecated globals have been removed from the expo package. expo-linear-gradient, expo-linking, expo-location, expo-permissions, and expo-sqlite are no longer automatically installed in every project. If you were depending on global.expo.LinearGradient or similar, please the respective package and import the API from there instead, eg: import { LinearGradient } from 'expo-linear-gradient';
expo-permissions has been deprecated in favor of module-specific permissions methods, eg: Permissions.askAsync(Permissions.CAMERA) ➡️ Camera.requestPermissionsAsync().
Android apps now target Android R (11 / SDK 30). This comes with some significant changes for location permissions, media library (related to StorageAccessFramework), and constants. Please note that these changes also impact SDK <= 40 projects in Expo Go, but they will not impact SDK <= 40 standalone apps. Refer to expo.fyi/android-r for more information.
The recommended version of react-native-reanimated has been updated to v2. If you would like to use v2 features in your app, you need to add the Babel plugin. You can continue to use v1 features (eg: those used by React Navigation v5) without adding the Babel plugin. Please note that if you use the new features from v2, you will not be able to use remote JS debugging in your app! This is only possible in v2 using Flipper, which is not yet fully supported in the managed workflow.
The new version of react-native-screens (v3) “enables screens” by default. If you encounter any related issues, you can report the issue and opt out with enableScreens(false).
lottie-react-native has been updated to the latest version! Your existing animations should continue to work as before, but if you encounter any issues please file an issue and share the animation file.

Known regressions

Outstanding

Bitcode has been disabled on SDK 41 standalone apps for iOS, pending facebook/facebook-ios-sdk#1698.

Resolved

Textures in expo-gl on Android are not currently working in published SDK 41 projects in Expo Go or standalone apps. Related pull request.
lottie-react-native crashes on iOS. Related pull request.

How to try out the beta release

You will be able to opt in to using the SDK 41 beta by setting the EXPO_BETA environment variable to 1 (or some truthy value).

On macOS and Linux, you can set this per command with EXPO_BETA=1 expo <command>. On Windows, you can do the same with cross-env: npx cross-env EXPO_BETA=1 expo <command>. Below we have listed in the commands in their more concise form.

Install the latest version of expo-cli:

npm i -g expo-cli (SDK 41 requires expo-cli@4.3.2 or greater)

Initialize a new project with SDK 41 beta:

EXPO_BETA=1 expo init

Upgrade an existing project:

EXPO_BETA=1 expo upgrade

Install the latest Expo Go for iOS to your simulator:

EXPO_BETA=1 expo client:install:ios outside of an Expo project or inside of an SDK 41 project

Install the latest Expo Go for iOS to your physical device:

Use this TestFlight open beta link and follow the instructions.

Install the latest Expo Go for Android:

EXPO_BETA=1 expo client:install:android outside of an Expo project or inside of an SDK 41 project.

Running other CLI commands

Other commands will work as expected without the EXPO_BETA environment variable, including build:{android,ios}.

Read the documentation by selecting it from the version selector in the API reference section:

https://docs.expo.io/versions/v41.0.0

What to test

Try ejecting your app and running it: expo eject. Did it work without any changes? Perfect! No? Please report it on the SDK 41 Beta Eject Issues Issue.
Media library and permissions changes made for Android R may impact your app. We'd appreciate your feedback on how they work for your app.
Did we miss updating the documentation somewhere? Let us know.

How to report issues

Create an issue on https://github.com/expo/expo/issues and be sure to fill out the template.
Figuring out the underlying causes of issues is super helpful.
Let us know that you are using the SDK 41 beta so we can prioritize the issue.

Thank you for helping us with testing the release, we look forward to shipping it soon! 🚀

Expo Application Services (EAS): Build and Submit

Expo Team — Tue, 15 Dec 2020 19:31:09 +0000

Today we're excited to announce the public preview of two brand new services: EAS Build and Submit. These are the first services available from Expo Application Services (EAS), our new cloud services.

EAS Build

Feature Preview

EAS Build is a new service that takes everything good about the Expo build service (expo build:[ios|android]) and makes it available to all React Native apps. You can set your app up to build for distribution in minutes or even less, thanks to automatically managed app signing credentials and defaults that just work for most Expo and React Native apps.

In this screenshot, we go from a brand new project to release build running on EAS Build in 30 seconds.

We've also added support for "internal distribution" - a feature that makes it easy for you to share test builds with colleagues and friends without going through an app store, by using ad hoc provisioning on iOS and standard APK side-loading on Android. Generating and updating the ad hoc provisioning profile can be handled entirely for you by EAS Build.

Easily share builds with your team using “internal distribution”.

EAS Build currently works best with bare React Native apps. If you use the Expo managed workflow and end up needing to move to the bare workflow, you can transition seamlessly to EAS Build - just run eas build instead of expo build after ejecting.

Coming later in 2021: full support for Expo managed workflow

With EAS Build, you can include libraries with native code that aren't part of the Expo standard library. For many of you, the Expo managed workflow is nearly a perfect fit - except for that one piece of functionality you absolutely have to have in your app, but that isn't part of the Expo standard library (whether that's IAP support, WebRTC, Bluetooth, or something more esoteric).

EAS Build will let you use any compatible library from GitHub or npm or that you write yourself, even if it has native code in it.

EAS Build also lets you build smaller, stripped-down binaries that include only the code your application needs, which means a smaller install size for your users.

There's already early support for Expo managed apps in EAS Build in the preview, but it's not quite ready for production yet. There's also a big missing piece: how do you get a new version of your Expo development client app that includes your bespoke native runtime? We're working on this, and we'll have answers for you in the coming months.

These are some of the most common requests we hear from Expo developers today, so we're extremely excited to be close to getting a solution into your hands.

EAS Submit

Feature Preview

When you want to put your app into the App Store and Play Store, you can use a single command from your terminal or from CI to submit it.

When you run eas submit, your app binary will be uploaded to EAS and then submitted to the respective app store from there. This means fewer dependencies to install on your machine, and that you can submit your apps from your Windows, Linux, or macOS computer to any app store.

We guide you through your first submission and try to make your nth submission as easy as possible by catching common mistakes and giving you guidance on how to resolve them. For example, if you're missing a privacy policy, we have an FYI for that.

Expo Application Services (EAS)

Expo is the open source project, and Expo Application Services offers hosted cloud services built for both Expo and React Native.

You won't need EAS to use Expo, which will always be open source and free. You can choose a different CI/CD service or use your own hardware.

Likewise, you'll be able to take advantage of EAS with any React Native project, whether or not it uses Expo's open source tools. EAS is designed for developers who specifically want their builds, updates and/or other parts of their app operations, development and collaboration workflows streamlined by a cloud service designed purposefully for and deeply integrated with React Native and Expo.

How does EAS relate to the Expo services that I'm already using for builds, updates, and notifications?

We don't want to disrupt anyone who is counting on Expo services to make software, and so we'll continue to operate the existing build, update, and notification services indefinitely. So, if you're happy with the way you're using those services now, you don't need to do anything differently and you can continue using them.

To reduce confusion with EAS versions of the services, we're going to start calling the existing free services the "Classic" Expo services. So, "Classic" Build, Updates, and Notifications.

That said, EAS is where most of our investment and effort on the services side will go in the future, so you should expect to see each EAS service keep getting better, more powerful, and easier to use as time goes on. Keep an eye out for the EAS Update preview, launching in early 2021.

How much will EAS services cost to use?

We'll always maintain a free tier that can meet the needs of individual and hobbyist developers building small apps. We'll announce further pricing details closer to the date when EAS services graduate from preview in 2021.

If I'm already an Expo Developer Services subscriber, how does this affect me?

If you're currently paying for Expo Developer Services, we've automatically updated your plan to EAS Priority Plan. EAS Priority will have the same price point and feature set as your old Developer Services plan, plus preview access to EAS Build and Submit. You don't need to do anything: you'll be moved over automatically.

How can I try EAS Build and Submit right now?

The previews of EAS Build and Submit are available to developers subscribed to the EAS Priority Plan. If you're not yet a subscriber, you can try it out for free for a month. If you want to try the preview services out but don't have access to a credit card, please reach out to us on Twitter and we can help you out.

Once you're signed up, you can find everything that you need to know in the Feature Preview documentation. If you'd like to watch a quick video walkthrough of EAS Build and Submit, check out this YouTube video:

DEV Community: Expo

Control SwiftUI and Compose State Synchronously with Worklets in Expo UI

How this actually works

Input masking without flicker

Beyond input masking

Getting started

How to upgrade to Expo SDK 56

Key things to know as you upgrade to SDK 56

Power your SDK upgrade with Claude Code

Faster native builds

Expo Go update

Hermes bytecode diffing for updates is enabled by default

Inline Expo Modules

Tips for upgrading your Expo SDK

Use the upgrade skill!

Troubleshoot with Expo MCP

Check the changelog

Using development builds over Expo Go

New Architecture advice

Check the troubleshooting guides

Reach out if you need a hand!

Expo SDK 56

Expo UI is now ready for production

Universal components

Stable native APIs

Drop-in replacements for community components

Faster native builds

Precompiled Expo packages on iOS

Precompiled headers for Android codegen (experimental)

Expo Modules: easier to write, faster to run

Inline modules

Type generation tools

Revamped create-expo-module

Runtime performance improvements in expo-modules-core

React Native 0.85 and React 19.2

Hermes bytecode diffing is now enabled by default

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

Status bar and navigation bar APIs are now consistent

New Calendar, Contacts, and MediaLibrary APIs are now stable

Widgets for iOS promoted to stable

AI-friendly project scaffolding

Convex integration

Expo CLI

Type-safe config plugins

Expo Router

New features

Brownfield: more flexibility for embedded Expo apps

Expo Application Services (EAS)

Build time statistics for xcodebuild and Gradle

Prebuilt artifacts for major community libraries

Coming soon: EAS Observe

Other notable changes

Deprecations

Notable breaking changes

Tool version bumps

Expo Go

Upgrading your app

Thanks to everyone who contributed to the release!

ASO Skills: ASO in Your AI Workflow

Why shipping fast made App Store discovery harder

What is App Store Optimization (ASO)?

ASO Skills: bringing App Store Optimization into your AI workflow

Build, ship, and optimize your app in one workflow

How to keep your OTA updates lean and fast

EAS Update pricing recap

Monthly Active Users (MAUs)

Bandwidth

Why smaller updates matter

Optimize your assets

Let your assets be assets

Choose which assets go into your updates

Submit to the app stores regularly

Keep your JavaScript bundle in check

Shipping updates efficiently

Use rollouts for production updates

Use updates for internal testing and PR previews

Keeping track of your usage

Monitor your usage in the dashboard

Use the pricing calculator to find the right plan

Pick the plan that fits today

Revamped `create-expo-module`

Runtime performance improvements in `expo-modules-core`

More capable `expo-file-system`