u/EvanJBacon

Would love to get some more insight on things like text input in a web page. Anyone have a read on the best person to ask? Tried replying on X but didn't get much response.

it's surfers [dot] expo [dot] app

the autoplay mode is buggy, happy trails!

Also interested in this. Would love to use a bluetooth keyboard instead of the wristband, when developing.

This is great! Curious how you did authentication? I can't figure out a good way to use the keyboard in websites.

Try using Expo DOM Components. We have a template `bunx create-expo -e with-shadcn` that may give you some inspiration on how to use it in your app. DOM Components are designed to make incremental migration from web to native much easier as they let you use web code inside of a webview, but restricted to the component boundary. Data and navigation should still be managed by the app. They work in Expo Router and enforce the use of native transitions between pages which gets you pretty far. If you adopt this system then you can go route-by-route migrating the most important screens over to native without needing to rewrite everything all at once. As for performance, WKWebViews have shared resource pooling which makes multiple instances work reasonably well. If your device runs low on memory then the webviews will be unloaded automatically. Expo DOM Components manage the lifecycle of the webview and will renew the views when the managing component becomes focused again.

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

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.

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

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

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.

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.

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.

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.

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.

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.

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

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

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

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.

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.

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.

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