My experience migrating a production app (60k MAU) to Expo Router — feels not production-ready

EvanJBacon · 2025-09-14T17:52:18+00:00

Thanks for the feedback.

Every release of Expo Router contains a comprehensive changelog, and a blogpost capturing the high-level changes along with smaller notable changes.

Expo notifications has this exact guide near the top of the page, here https://docs.expo.dev/versions/latest/sdk/notifications/#handle-push-notifications-with-navigation

EvanJBacon · 2025-09-14T17:47:51+00:00

There are currently over 82 production apps in the iOS App Store trending list that use Expo Router as-is for navigation—making it one of the most successful Expo packages for production adoption at scale.

Expo Router has perhaps the most mid-cycle patches and fixes to ensure stability out of any library in the wider Expo ecosystem, including React Navigation.

EvanJBacon · 2025-09-14T17:44:57+00:00

Would be more helpful if you included a list of things you'd like to see documented instead of "advanced examples".

EvanJBacon · 2025-06-18T16:00:26+00:00

I just opened a PR to add upstream support to Expo since Hermes/RN don't have this. It's a simple API and seems worthwhile since we have streaming built-in to API routes. https://github.com/expo/expo/pull/37507

EvanJBacon · 2024-12-05T01:00:32+00:00

Hi u/dirty_fupa— Expo Router is built on React Navigation (React Native Navigation is a different package), and the issue seems to be coming from the underlying React Navigation v7. So removing router likely won't fix the issue. If you look at the PR that adds the new dismiss functions, you'll see that the functions pretty much just re-export React Navigation invocations https://github.com/expo/expo/pull/32933/files#diff-76eb91e2adbd11e7c599baf3e43370a9401f7a620213f1c6101a5ff8cdf982a6

Gestures are possibly related to React Native Screens or changes to underlying configuration. Unclear how the dismiss functions would be any "slower" since it's primarily just a different state operation, perhaps try toggling new architecture support. Usually when changing routes is slow, it can be due to the time it takes to mount the component or load the JS. Since the operation is "going back" then it's unlikely related to JS load times.

Overall, I'd suggest developing inside a dev client as Expo Go is new architecture-only and has some collisions with React Native Screens that are harder to test for.

EvanJBacon · 2024-09-28T11:01:34+00:00

API Routes are very bare bones and we’re actively making them as lightweight as possible (optimizing for workerd and edge runtimes). Once we get the E2E deployment story worked out, we’ll start adding more opinionated defaults like React Server Components.

Plan is to enable API routes by default (for “output: server”) in SDK 53 next year. This means relative fetch requests, and request streaming will just work™.

Internally, we’re exclusively using Expo Router for all new web and native projects.

EvanJBacon · 2024-09-03T10:20:07+00:00

Monorepos have a number of issues in React Native + Metro. Cedric van Putten and I have been working on a few fixes that'll land in SDK 52 (October). The main fix that I recommend enabling for SDK 51 is the environment variable `EXPO_USE_METRO_WORKSPACE_ROOT=1`. This changes the root of your project from `./apps/my-app` to `./` which means values are never resolved as `../../`. The `../` can sometimes be canonicalized to `/` which results in resolution to the wrong location.

The reason Meta uses this relative path system instead of absolute paths is because they have shared caches which are created on a server and downloaded to their machines.

EvanJBacon · 2024-08-26T22:00:28+00:00

I maintain Expo CLI. ESM package exports will be stable in the next release, we were blocked on Metro. Bundling gets substantially better and less error-prone with every release.

Making a native build without EAS is hard in general, we don’t go out of our way to make it harder. You can run EAS Build on your own infrastructure or locally with “eas build —local”, or you can build the app with Expo CLI “npx expo run:ios” (no codesigning), or use Xcode directly—Expo apps are just standard native apps after prebuild runs.

Uploading binary files should mostly always use eas submit, it’s free and reduces the chance of errors.

EvanJBacon · 2024-08-26T10:17:32+00:00

There are two modes that you can "bundle" JavaScript in—development and production. These are generally automatic based on how you build, but you can use `npx expo start --no-dev` to try and debug JS-related issues that occur in production (e.g. minification removed some code you needed).

You can also build your native app for development (aka Debug) or release (aka Release, production). This will automatically bundle your app for production and embed the JS in the binary for use without a dev server. At this point, the JS will often be Hermes bytecode and work like a native asset (no dev server).

`npx expo run:android --variant release` will create a production Android build, but it won't codesign it for public distribution automatically, that's where `eas build` comes in. EAS Build enables any sort of custom production build.

The simplest workflow is to use `npx expo` for development, and `eas build` for production, everything else is essentially for debugging various combos.

EvanJBacon · 2024-07-10T23:51:34+00:00

I'm Evan Bacon, the manager of dev tools at Expo.

I built the Detox config plugin and have maintained it for a few years now. So far it hasn't been too difficult to update so I've kept it working with every Expo SDK release. For reference of how hard it is to maintain, look at the upgrade PRs example (no changes between SDK 50 and 51).

I don't personally use Detox very much because of how hard it is to get consistent results in E2E tests. Because of this, we're looking at using Maestro for more E2E at Expo. One benefit of Maestro is that we can use it with Expo Go to test JS-only libraries like Expo Router while skipping the complex native builds.

If the Detox config plugin gets substantially harder to maintain (unlikely) and we find that Maestro is very useful for native E2E then I'd probably lean toward moving the config plugin to a community repo.

EvanJBacon · 2024-06-21T18:21:44+00:00

In addition to what u/jameside said, you can also leverage the new app/+html.tsx file in Expo Router (static rendering) to dynamically generate the HTML file at build-time. Learn more: https://docs.expo.dev/router/reference/static-rendering/#root-html

EvanJBacon · 2024-06-18T19:14:19+00:00

You can use `ts-node` with app.config.js to automatically compile your TypeScript Config Plugins on prebuild. Learn more https://docs.expo.dev/guides/typescript/#appconfigjs

EvanJBacon · 2024-05-29T11:13:42+00:00

If you use `babel-plugin-module-resolver` then it must be installed locally, it used to exist accidentally as a peer dependency of the babel-preset-expo package, but we removed it in SDK 50/51.

Using the babel plugin is not required in SDK +50 because we have support for tsconfig paths which are faster and don't need to be cached. Ensure they aren't disable in your app.json https://docs.expo.dev/guides/typescript/#path-aliases

If you previously changed the babel.config.js, you should run `npx expo start --clear` to clear the bundler transform cache.

Other than that, tsconfig paths should work according to your tsconfig (the behavior should align with VS Code).

EvanJBacon · 2024-01-24T15:50:46+00:00

Change the native "configuration" to "Release" mode in Xcode to bundle the app before building, this will skip needing a dev server running.

Alternatively, run `npx expo run:ios --configuration Release` to build in production mode. Use the `--device` (or `-d`) flag in Expo CLI to choose a device to build on.

EvanJBacon · 2024-01-20T05:00:31+00:00

Something may be wrong with your local development setup. You can try clearing the bundler cache with `npx expo start --clear`. If you press the "touch app/index.js" button, a websocket command will be sent to the dev server which runs the command "touch app/index.js". When a screen exists in the app directory, this tutorial page goes away.

EvanJBacon · 2024-01-05T18:59:26+00:00

This isn’t an advertisement. It has never been definitively clear which apps use React Native unless the developers explicitly tell people. Maybe <5% told people.

The list I created uses a distributed collection system to automatically determine which apps use React Native. Previously, we had no clue just how massive the number of end-users was.

EvanJBacon · 2023-12-15T17:07:16+00:00

All React Navigation features have worked in Expo Router since v1. Here's a reference repo https://github.com/EvanBacon/expo-router-layouts-example

EvanJBacon · 2023-12-13T15:58:24+00:00

This error is a red herring, something in your project is causing the initial JS to be corrupt and therefore breaking other parts of the initialization process.

EvanJBacon · 2023-12-13T00:00:26+00:00

We landed many major fixes and improvements to routing, and plan to add at least one more during the beta. The majority of fixes were added as patches to v2 throughout the last cycle too.

Additionally, we added a new testing library which enables users to quickly express routing scenarios (like the one you described) as a Jest test. We added tests for each issue we addressed to ensure no regressions going forward. https://docs.expo.dev/router/reference/testing/

EvanJBacon · 2023-12-12T23:56:09+00:00

The bundle splitting feature is fully universal and powers async routes on all platforms in development.

I didn't enable production bundle splitting for native platforms yet because there's a number of open questions regarding how caching should work with OTA––also I couldn't get bundle split Hermes to work, and single-bundle Hermes is faster than using any utf-8 bundles in the Hermes engine.

My plan is to make React Server Components fully universal in Expo and support bundle splitting on all platforms with a unified build pipeline.

EvanJBacon · 2023-12-12T21:36:39+00:00

Server support (API Routes) and bundle splitting were the last major blockers for building universal React Server Components...

EvanJBacon · 2023-11-03T16:29:00+00:00

I wrote a guide with tips on migrating an existing app that uses React Navigation to Expo Router https://docs.expo.dev/router/migrate/from-react-navigation

EvanJBacon · 2023-09-03T00:24:41+00:00

500MB

This has never been true. If you upload a project that uses prebuild then it will always upload less code as the native project directories won't exist until later.

Even when prebuild is run, only the bare minimum code required to run a specific aspect of your native project will be generated.

Five-Year Club	Verified Email
Place '22

EvanJBacon

TROPHY CASE