DEV Community: Dan

Expo Router v56 Ships SSR and Breaks Free from React Navigation

Dan — Wed, 10 Jun 2026 13:15:36 +0000

Expo Router just made its biggest change since launch. Version 56 forks from React Navigation, adds streaming server-side rendering, and gives Android developers the toolbar API they've been waiting for.

The fork is the big story here, affecting every Expo Router app. But there's more: new SSR capabilities, an Android toolbar that matches iOS, and expanded Native Tabs. Let's break down what changed and why it matters.

The React Navigation fork explained

Expo has deep roots with React Navigation. Brent Vatne, Expo's VP of Engineering, led React Navigation through versions 1.0 and 2.0 alongside @ericvicenti and @satya164. We helped React Navigation grow from an early experiment, influenced by React Native's NavigationExperimental and our own ex-navigation, into the standard navigation solution for React Native.

React Navigation remains in Satya's capable hands while our focus shifted to Expo Router. As Expo Router evolved, we needed deeper control over React Navigation's internals. After talking with Satya, we agreed that forking the pieces Expo Router depends on would serve both projects better.

This isn't about abandoning React Navigation. It's about giving each project room to grow in different directions.

For Expo Router, the fork opens space for changes specific to file-based routing, web features, and server rendering. Some improvements we want to make wouldn't help React Navigation users directly, and pushing those changes upstream would add unnecessary complexity.

We can now create a focused version of React Navigation's internals that works specifically for Expo Router. This lets us simplify integration, reduce workaround code, and make maintenance easier.

There's also a practical benefit: dependency versioning. Projects sometimes ended up with multiple React Navigation versions installed, causing conflicts. Forking the internal pieces gives us better control over compatibility and makes releases more predictable.

Expo Router's web capabilities like data loaders and server-side rendering need changes that are easier to make in a codebase built specifically for these features.

How the fork affects your code

Since Expo Router no longer depends on React Navigation, you can't import code directly from @react-navigation/* packages. We know this breaks existing code, so we built tools to help with migration.

Use our codemod to migrate all React Navigation imports to expo-router/react-navigation:

Our migration guide walks through manual migration steps. To ease the transition, imports of @react-navigation/core from libraries will automatically redirect to expo-router/react-navigation for at least one release cycle.

If you run into problems, let us know.

What's next for both projects

We're working with the React Navigation team on a shared API for library authors who need to support both libraries.

If you maintain a library that should work with both Expo Router and React Navigation, reach out. We'd like to collaborate on adapting it to the new APIs.

Custom Suspense fallbacks

You can now customize the Suspense fallback for routes within a _layout. Export a [SuspenseFallback](https://docs.expo.dev/router/error-handling/#loading-states-with-suspense-fallback) to customize the loading screen:

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 Layout() {
  return <Stack />;
}

Streaming SSR arrives

Expo Router already supported API routes, middleware, data loaders, and static rendering. Version 56 adds streaming server-side rendering, which improves perceived performance by letting you prioritize important UI elements over slower, data-dependent components.

Enable it by setting unstable_useServerRendering to true in your Expo Router config.

Streaming SSR includes a new way to generate HTML metadata using a generateMetadata function.

We also added helper utilities for type-safe data loaders: [createStaticLoader](https://docs.expo.dev/versions/latest/sdk/server/#createstaticloaderfn) and [createServerLoader](https://docs.expo.dev/versions/latest/sdk/server/#createserverloaderfn).

Android gets the toolbar

SDK 55 brought toolbar support to iOS. Version 56 adds the same feature to Android, achieving cross-platform compatibility. Like iOS, you can place the Android toolbar in three positions: left, right, and bottom.

See all available options in the toolbar documentation.

Native Tabs expansion

Last fall, in Router v6 (we changed our Router naming convention since then), we added Native Tabs support. We're working toward full cross-platform support and plan to mark the API as stable in the next release.

Expo Router v56 adds new options to Native Tabs. The most requested feature was preventing tab selection. You can now use the disabled property to show a tab in the tab bar while preventing user interaction.

Check all available options and platform support in the Native Tabs reference page.

Getting started with v56

Three key takeaways from this release:

The React Navigation fork requires a one-time import update for every Expo Router app. Our codemod and compatibility layer make migration straightforward.

Streaming SSR, generateMetadata, and new loader helpers improve web experiences with Expo Router.

Android now has toolbar support and expanded Native Tabs, matching iOS feature parity.

For existing apps, start with the migration guide and run the codemod. New projects get all these features by default in SDK 56.

Find us on Discord and GitHub. We want to hear what you build and when something breaks.

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

Write Swift and Kotlin directly in your React Native app with Expo SDK 56

Dan — Tue, 09 Jun 2026 13:19:36 +0000

Working with native code in React Native usually involves creating separate packages and manually maintaining TypeScript interfaces. Expo SDK 56 changes this by letting you write Swift and Kotlin files right alongside your React components and automatically generating the TypeScript types for you.

Writing Expo modules traditionally meant dealing with package boilerplate and keeping multiple interfaces in sync. You'd create a module as a standalone package, then manually maintain TypeScript interfaces that matched your native Swift and Kotlin code. This workflow worked but added friction.

SDK 56 introduces inline modules and the expo-type-information package to remove these pain points. You can now write native modules directly in your project structure and generate matching TypeScript types automatically.

Writing native code next to your components

Inline modules let you place Swift and Kotlin files anywhere in your project structure. Need a custom native view? Create NativeView.kt and NativeView.swift files right next to your App.tsx and write your view there.

Setting up inline modules is simple. In your app configuration file, specify watchedDirectories - the directories containing your inline modules. After running npx expo prebuild to sync the native projects, you're ready to go.

{
  "expo": {
    "experiments": {
      "inlineModules": {
        "watchedDirectories": ["app"]
      }
    }
  }
}

With "app" in your watchedDirectories, you can create Swift and Kotlin files anywhere within the app directory or its subdirectories. Open app/nested/InlineModule.swift and write your Expo module:

internal import ExpoModulesCore

class InlineModule: Module {
  public func definition() -> ModuleDefinition {
    Constant("Hello") {
      return "Hello iOS inline modules!"
    }
  }
}

Once written, access it from JavaScript using requireNativeModule('InlineModule'). For views, use requireNativeView('InlineModule').

Automatic TypeScript type generation

The expo-type-information package parses your Swift modules and generates matching TypeScript types automatically. This eliminates the manual work of maintaining type interfaces.

The package includes a CLI tool with commands designed for inline modules.

The inline-modules-interface command finds all Swift inline modules in your project and generates two TypeScript files for each one. After running the command, you'll see these files appear next to your Swift file:

The Generated File ([ModuleName].generated.ts) contains all type information about the module, including function declarations, constants, classes, and views. This file gets overwritten every time you run the command.

// InlineModule.generated.ts
/*Automatically generated by expo-type-information.*/

import { ViewProps } from 'react-native';

import { NativeModule } from 'expo';

export declare class InlineModuleNativeModuleType extends NativeModule {
  readonly Hello: string;
}

The Stable File ([ModuleName].tsx) re-exports the module interface and provides a default export for the main view if one exists. You can edit this file and it won't be overwritten.

// InlineModule.tsx
// File hash: 8dfc86f5416afbe08cc1ee581c850fc9cec446479211d85501d9a5e2d24cc534
import { InlineModuleNativeModuleType } from './InlineModule.generated';

import { requireNativeModule, requireNativeView } from 'expo';

const InlineModule: InlineModuleNativeModuleType =
  requireNativeModule<InlineModuleNativeModuleType>('InlineModule');

export const Hello: string = InlineModule.Hello;

This split lets you tweak imperfect generated output while still allowing core declarations to be regenerated when you update the native side.

Current limitations

File naming requires that an inline module's name exactly matches its file name. Module names must be globally unique since the name identifies the module in the global object. You can't have both app/InlineView.swift and src/InlineView.swift in the same project.

Type generation currently only works for Swift modules and on macOS.

When types can't be resolved

Sometimes the tool can't resolve types of native module declarations. This happens because of SourceKitten limitations and our decision to parse only provided files instead of doing full compilation. When we can't resolve a Swift type, we generate an unknown type in TypeScript.

Common scenarios include nested declarations where SourceKitten has trouble with deeply nested closures, making it hard to find types inside a Class. Consider this ExpoBlob module:

// ExpoBlob.swift
import Foundation
import ExpoModulesCore

public class ExpoBlob: Module {
  public func definition() -> ModuleDefinition {
    Name("ExpoBlob")

    Class(Blob.self) {
      Constructor { (blobParts: [EitherOfThree<String, Blob, TypedArray>]?, options: BlobOptions?) in
        let endings = options?.endings ?? .transparent
        let blobPartsProcessed = processBlobParts(blobParts, endings: endings)
        return Blob(blobParts: blobPartsProcessed, options: options ?? BlobOptions())
      }

      Property("size") { (blob: Blob) in
        blob.size
      }

      Property("type") { (blob: Blob) in
        blob.type
      }

      Function("slice") { (blob: Blob, start: Int?, end: Int?, contentType: String?) in
        let blobSize = blob.size
        let safeStart = start ?? 0
        let safeEnd = end ?? blobSize

        let relativeStart = safeStart < 0 ? max(blobSize + safeStart, 0) : min(safeStart, blobSize)
        let relativeEnd = safeEnd < 0 ? max(blobSize + safeEnd, 0) : min(safeEnd, blobSize)

        return blob.slice(start: relativeStart, end: relativeEnd, contentType: contentType ?? "")
      }

      AsyncFunction("text") { (blob: Blob) async -> String in
        await blob.text()
      }

      AsyncFunction("bytes") { (blob: Blob) async -> Data in
        let bytes = await blob.bytes()
        return Data(bytes)
      }
    }
  }
}

// ExpoBlob.generated.ts
/*Automatically generated by expo-type-information.*/

import { ViewProps } from 'react-native';

import { NativeModule } from 'expo';

// These types haven't been defined in provided file(s).
export type Data = unknown;
export type TypedArray = unknown;

export type BlobOptions = {
  type: string;
  endings: EndingType;
};

export enum EndingType {
  transparent = 'transparent',
  native = 'native'
}
export enum BlobPart {
  string = 'string',
  blob = 'blob',
  data = 'data'
}

export declare class Blob {
  slice(
    blob: Blob,
    start: number | undefined,
    end: number | undefined,
    contentType: string | undefined
  ): unknown /*The type couldn't be resolved automatically.*/;
  text(blob: Blob): Promise<string>;
  bytes(blob: Blob): Promise<Data>;
  readonly size: unknown /*The type couldn't be resolved automatically.*/;
  readonly type: unknown /*The type couldn't be resolved automatically.*/;
  constructor(
    blobParts: (string | Blob | TypedArray)[] | undefined,
    options: BlobOptions | undefined
  );
}

export declare class ExpoBlobNativeModuleType extends NativeModule {
  Blob: typeof Blob;
}

Notice how the return types of slice, type, and size haven't been resolved. You can often fix this by manually annotating the return type of the closure in Swift.

Imported declarations also cause issues since we only parse provided files and ignore imports. If a function or type from outside influences a return value, the tool may not resolve it.

The tool struggles with return types if you omit the return keyword and don't explicitly annotate the closure. To avoid this, annotate DSL declarations or include the return keyword. Try using --type-inference PREPROCESS_AND_INFERENCE in the CLI for better return type inference.

How it works under the hood

Let's examine what happens when you use inline modules. Suppose you've created a module at app/nested/InlineModule.swift and set watchedDirectories to include the app folder.

{
  "expo": {
    "experiments": {
      "inlineModules": {
        "watchedDirectories": ["app"]
      }
    }
  }
}

Prebuild process

Running npx expo prebuild updates your native projects in two ways:

The Xcode project gets updated so the app folder becomes a file system synchronized group. This makes all files in the folder show up in the Xcode editor and get automatically included in the iOS build.

Project properties for both iOS and Android get updated with your watchedDirectories. On Android, this is essential for adding files to Android Studio. These properties are used later during autolinking.

// Podfile.properties.json
{
  "expo.jsEngine": "hermes",
  "EX_DEV_CLIENT_NETWORK_INSPECTOR": "true",
  "expo.inlineModules.watchedDirectories": "[\"app\"]"
}

// gradle.properties
# ...
expo.inlineModules.watchedDirectories=["app"]

Android project updates

On Android, the project updates during the Gradle configuration phase. This happens when you click Sync Project with Gradle Files in Android Studio or automatically before building the app.

During this phase, a folder structure gets created that mirrors your watchedDirectories. Symlinks are created to the Kotlin files inside those directory trees.

This mirror structure ensures native files get compiled and are visible in Android Studio, while other project files are ignored. JavaScript and TypeScript files won't be indexed by Android Studio since they're not in this mirror directory.

Module registration

All Expo modules live on a global object exposed through native module providers. During build on both iOS and Android, a module provider class gets generated containing references to all regular Expo modules and your inline modules. When you call requireNativeModule('InlineModule') in JavaScript, it accesses this global object.

Type generation internals

Type generation works by parsing the native module's structured declaration and generating its TypeScript interface directly from native code. The expo-type-information package has four main parts:

Swift parser
Abstraction over module types
TypeScript code generator
CLI tool

They work together to automate writing TypeScript interfaces for your modules.

Bridging type systems

When defining a module in the DSL, you provide the native interface with functions, constants, classes, and views - all strictly typed in Swift's type system.

When interfacing with the module from TypeScript, you're working with JavaScript objects under TypeScript's type system. This differs from Swift or Kotlin, and there's no strict one-to-one mapping between them. The conversions between JavaScript and Swift aren't always obvious.

Expo provides converters for many types, but multiple TypeScript constructs sometimes convert to the same Swift type.

For example, when working with Swift's UIColor, Expo can convert several JavaScript objects: color strings ('red'), hex strings (#00ffaa00), or hex numbers (0xff66dd00). All of these can be type-annotated differently in TypeScript - string, number and ColorValue (from react-native) all convert to UIColor.

Currently we only support mapping basic types (number, string, boolean, etc.). Check the exact list in the reference. We'll continue updating the package with additional type mappings based on converters available in expo-modules-core.

Library components

The expo-type-information package consists of several components working together.

Swift file parsing

We use SourceKitten to parse Swift files. SourceKitten provides structured information about the whole code, letting us parse the Swift DSL, enums, and structs.

Consider the Hello constant declaration from InlineModule.swift:

Constant("Hello") {
  return "Hello iOS inline modules!"
}

That Swift declaration corresponds to this SourceKitten output:

{
  "key.bodylength": 56,
  "key.bodyoffset": 124,
  "key.kind": "source.lang.swift.expr.call",
  "key.length": 66,
  "key.name": "Constant",
  "key.namelength": 8,
  "key.nameoffset": 115,
  "key.offset": 115,
  "key.substructure": [
    {
      "key.bodylength": 7,
      "key.bodyoffset": 124,
      "key.kind": "source.lang.swift.expr.argument",
      "key.length": 7,
      "key.offset": 124
    },
    {
      "key.bodylength": 48,
      "key.bodyoffset": 133,
      "key.kind": "source.lang.swift.expr.argument",
      "key.length": 48,
      "key.offset": 133,
      "key.substructure": [
        {
          "key.bodylength": 46,
          "key.bodyoffset": 134,
          "key.kind": "source.lang.swift.expr.closure",
          "key.length": 48,
          "key.offset": 133,
          "key.substructure": [
            {
              "key.bodylength": 46,
              "key.bodyoffset": 134,
              "key.kind": "source.lang.swift.stmt.brace",
              "key.length": 48,
              "key.offset": 133
            }
          ]
        }
      ]
    }
  ]
}

SourceKitten lets us parse just a single file. This saves time since it doesn't have to compile the whole Xcode project, which is essential when you want to constantly regenerate TypeScript interfaces. But not having access to the whole project means types and functions defined in other files can't be resolved.

Type information abstraction

An abstraction layer defines what type information is relevant for Expo modules. The abstraction is agnostic to the underlying native language, so we can add Kotlin support in the future. It's close to the TypeScript type system since it generates TS declarations. Our SourceKitten-based parser outputs this abstraction.

/**
 * `FileTypeInformation` object abstracts over type related information in a file.
 * The abstraction is closely related to Typescript and expo NativeModules (both to be independent of the actual native side
 * and to give accurate information about what and how we can use the given module).
 * @header TypeInfoTypes
 */
export type FileTypeInformation = {
  /**
   * @field Set of all type identifiers declared and used in the file.
   */
  usedTypeIdentifiers: Set<string>;
  /**
   * @field Set of all type identifiers declared in the file.
   */
  declaredTypeIdentifiers: Set<string>;
  /**
   * @field For parametrized types it is the maximum number of parameters this type is used with.
   * This map is useful if we want to infer how many parameters a type declared in other file has.
   *
   * For example if `Set<string>` exists in a file then inferredTypeParametersCount['Set'] == 1.
   * If `Map<number, string>` exists then inferredTypeParametersCount['Map'] == 2.
   * If you use both `SomeParametrizedType<Type1, Type2>` and `SomeParametrizedType<Type3>` then inferredTypeParametersCount['SomeParametrizedType'] == 2.
   */
  inferredTypeParametersCount: Map<string, number>;
  /**
   * @field Maps string identifier to the appropriate declaration object. For now only enum and records identifiers are mapped.
   */
  typeIdentifierDefinitionMap: TypeIdentifierDefinitionMap;
  /**
   * @field Array of all module classes declared in the given file.
   */
  moduleClasses: ModuleClassDeclaration[];
  /**
   * @field Array of all record classes declared in the given file.
   */
  records: RecordType[];
  /**
   * @field Array of all enums declared in the given file.
   */
  enums: EnumType[];
};

TypeScript emission

With Expo Modules types abstracted, we generate a TypeScript Abstract Syntax Tree (AST). We build this using the Compiler API with custom wrappers that handle different declaration types - imports, enums, classes, functions, types, interfaces. Once the AST is complete, we format the generated TypeScript with Prettier.

CLI interface

The CLI tool sits on top of everything. It exposes commands to work with regular modules, inline modules, and to debug the functions from previous steps.

Next steps

Check out the tutorials for inline modules and type generation, plus the reference pages for inline modules and the expo-type-information package.

Both features are experimental, so your feedback matters as we continue developing them. File an issue or create a pull request on GitHub, or share your thoughts on Twitter.

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

Swift Calls JSI Directly in Expo SDK 56: Removing the Objective-C++ Layer

Dan — Mon, 08 Jun 2026 20:28:57 +0000

SDK 56 makes JavaScript to native calls significantly faster on iOS by letting Swift talk to JSI directly. We eliminated the Objective-C++ layer and saw 1.6-2.3x performance improvements across our benchmarks.

Before this change, every native module call went through three languages. Now it's just Swift making a direct C++ call. Here's how we did it and what the performance gains look like.

The three-language problem

Prior to SDK 56, calling an Expo native module from JavaScript meant crossing multiple language boundaries. Your Swift module code sat behind an Objective-C++ translation layer (EXJavaScriptRuntime, EXJavaScriptValue, etc.), which then called into JSI's C++ implementation.

This architecture existed for one reason: Swift couldn't talk to C++ directly. Objective-C++ was the only practical bridge between them.

The performance cost was significant. Every call crossed two language boundaries in each direction. Each value got converted twice: std::string → NSString → Swift String, std::vector → NSArray → Swift Array. Each conversion allocated memory and copied data.

Three different languages in the call path meant three different ways to debug problems. Stack traces changed shape mid-call. Memory management worked differently at each layer. When something went wrong, you had to understand all three languages to fix it.

Swift/C++ interop changes the game

Swift historically needed Objective-C as a bridge to reach C++. Any C++ type had to be wrapped in an Objective-C class before Swift could use it.

Swift/C++ interop (introduced in Swift 5.9) removes this requirement. Swift can import C++ headers directly. The compiler automatically maps C++ classes and methods onto Swift types you can use naturally.

The result: what used to be a three-language relay race becomes a single Swift expression that compiles down to a direct C++ call. Performance matches what you'd get writing the call in C++ from the start.

We're not the first to explore this in React Native. Nitro Modules pioneered this approach when Swift/C++ interop was even less mature.

Building ExpoModulesJSI

ExpoModulesJSI is our Swift package that wraps JSI in Swift types. Despite the name, it's purely a JSI wrapper with no Expo-specific code. We could ship it standalone, but JSI only exists in React Native contexts, so the naming stays conservative.

The type system mirrors JSI exactly: JavaScriptRuntime, JavaScriptValue, JavaScriptObject, JavaScriptArray, JavaScriptFunction, etc. Each maps to its JSI equivalent but with a modern Swift API.

We preserve JSI's ownership model using non-copyable types. JSI's value types like jsi::Value and jsi::Object own runtime resources and follow move-only semantics. Swift 5.9's ~Copyable protocol lets us mirror this behavior. The Swift compiler enforces the same single-owner rules that JSI expects underneath.

The package builds as a SwiftPM package with C++ interop enabled, then gets bundled into an xcframework. Most React Native projects use CocoaPods, so we also provide a podspec that wraps the prebuilt binary. The podspec creates a stub xcframework at pod install time, then a build script runs the real SwiftPM build with content-hash caching.

Handling different concurrency models

React Native's threading predates Swift Concurrency. JavaScript runs on a dedicated thread with a run loop. Native work uses dispatch_queue_ts and callbacks. No actors, no await points, just queues and blocks with thread-switching contracts.

We wanted our Swift API to use modern Swift: async/await, structured concurrency, actor isolation where appropriate. This required building a bridge between Swift Concurrency and React Native's callback world without breaking either system's invariants.

The boundary layer handles most of this work. We'll skip the implementation details here since they could fill another post and the design is still evolving under production load.

Implementation challenges

Swift/C++ interop is experimental and comes with compilation costs. Here are the main issues we encountered:

Experimental status. Years after Swift 5.9, C++ interop remains opt-in and officially experimental. APIs and behavior can change between Swift versions. Not a blocker for us, but worth knowing.

Capability gaps. Swift and C++ have different memory models. ARC and value semantics versus manual lifetime management and raw pointers. Complex template metaprogramming and some inheritance patterns have no clean Swift mapping. Some gaps will close with tooling improvements; others are conceptually unbridgeable.

Compilation performance. Enabling C++ interop adds noticeable compile time per file. It also spreads: any module importing an interop-enabled module must enable interop too. We solve this by shipping prebuilt xcframeworks. Apps link against binaries instead of recompiling interop sources, and downstream modules see a regular Swift library.

Generated headers. Swift emits a C++ header exposing all public symbols to C++. This gets large quickly and sometimes emits declarations in the wrong order. There's an undocumented flag -clang-header-expose-decls=has-expose-attr that restricts the header to explicitly annotated declarations. It's mentioned only in FrontendOptions.td in the Swift compiler source.

Third-party type annotations. Swift imports C++ classes as value types by default, but types with virtual methods need reference semantics. For code we control, Swift provides macros like SWIFT_SHARED_REFERENCE. For third-party headers like JSI, we use Clang's APINotes - YAML files that add import attributes without modifying the original headers.

Exception handling. C++ exceptions don't cross into Swift. Swift assumes imported C++ functions don't throw unless proven otherwise. When JSI methods like evaluateJavaScript throw jsi::JSError, the exception crashes the app if it reaches Swift frames. We built a bridge that catches C++ exceptions, stores them in thread-local storage, and rethrows them as Swift errors after each call.

Performance benchmarks

Our goal was simple: don't sacrifice performance for better Swift APIs. Turbo Modules set the bar for modern React Native native modules, and we wanted to match that performance while providing superior ergonomics.

Methodology

We tested four micro-benchmarks across three native module architectures on two SDK versions. Each benchmark ran 100,000 iterations, averaged across three trials on an iPhone 16 Pro release build:

Sync no-op function
Adding two numbers (0 + 1)
String concatenation ('hello' + 'world')
Async no-op function

The architectures tested were Expo Modules, React Native Turbo Modules, and the legacy Bridge. We used trivial inputs intentionally - these measure boundary crossing costs, not computation costs.

Note on async testing: Expo Modules use Swift Concurrency (async/await), which requires more work per call than callback-style async (Task creation, continuations, scheduler interaction). Turbo Modules and Bridge use callbacks. This compares the same logical operation done idiomatically in each system.

Results

CODE_BLOCK_N

Expo Modules became 1.6-2.3x faster across all benchmarks. The improvements match our architectural changes: boundary costs dominated the no-op test, marshaling costs affected strings most, and async showed the largest absolute gains due to removed overhead.

Before SDK 56, Expo Modules trailed Turbo Modules on every test. After the rewrite, we match Turbo Modules on simple sync calls and lead by 55% on async operations. The async advantage matters most in real apps where promises chain across module boundaries.

Turbo Modules also improved between SDK 55 and 56 from upstream React Native changes, so we were catching up to a moving target.

The Bridge results show the old story: 3-4x slower on sync operations due to JSON serialization overhead. The async gap narrows to 1.6x because Promise allocation and scheduling costs affect all architectures similarly.

Limitations

These micro-benchmarks measure boundary crossing costs. Real app performance depends on call frequency, payload size, and actual work being done. Device differences, OS versions, and Hermes builds will shift absolute numbers, but the performance ratios should remain consistent.

What comes next

Removing the Objective-C++ layer makes previously difficult features straightforward to implement. It also opens up performance optimizations that are now practical with a single-language call path.

This rewrite provides the foundation for the next round of API improvements we're planning.

Using SDK 56 native modules

SDK 56 ships the new native module architecture on iOS, tvOS, and macOS. Check the SDK 56 release notes for complete details. The expo-modules-jsi package is available on GitHub for bug reports, feature requests, and contributions.

Android takes a different approach in SDK 56. The major win there is our Kotlin compiler plugin, which moves more work to compile time and delivers larger performance gains than a JSI rewrite would provide. We may explore a Kotlin-first JSI wrapper eventually, but Android's JSI performance was already in better shape.

One final note: AI significantly accelerated this rewrite. It covered almost the entire JSI C++ surface in Swift and pushed test coverage to nearly 90%. Doing this work manually would have taken much longer.

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

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!

DEV Community: Dan

Expo Router v56 Ships SSR and Breaks Free from React Navigation

The React Navigation fork explained

How the fork affects your code

What's next for both projects

Custom Suspense fallbacks

Streaming SSR arrives

Android gets the toolbar

Native Tabs expansion

Getting started with v56

Write Swift and Kotlin directly in your React Native app with Expo SDK 56

Writing native code next to your components

Automatic TypeScript type generation

Current limitations

When types can't be resolved

How it works under the hood

Prebuild process

Android project updates

Module registration

Type generation internals

Bridging type systems

Library components

Swift file parsing

Type information abstraction

TypeScript emission

CLI interface

Next steps

Swift Calls JSI Directly in Expo SDK 56: Removing the Objective-C++ Layer

The three-language problem

Swift/C++ interop changes the game

Building ExpoModulesJSI

Handling different concurrency models

Implementation challenges

Performance benchmarks

Methodology

Results

Limitations

What comes next

Using SDK 56 native modules

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

Revamped `create-expo-module`

Runtime performance improvements in `expo-modules-core`

More capable `expo-file-system`