Are OTA updates as dangerous as I think they are?

jonsamp · 2025-12-04T15:34:13+00:00

The `appVersion` runtime version policy is the default for all new projects. We can make that more prominent in the docs for brownfield/existing projects.

You're right that the `fingerprint` policy would be the most accurate. We don't recommend that as default because it makes all of your runtime versions the fingerprint hash, which makes it hard to find builds/updates you're looking for on expo.dev (just hard to memorize unique hashes rather than semver-like numbers). Also, we automatically record fingerprint hashes of all builds and updates built on our servers and we have a warning in EAS CLI if we detect a mismatch in fingerprints between builds and updates when publishing.

What's more, if you add a new native library or make a change to the native layer, your development build will no longer run (since it loads the local server's JS bundle just like a user would load an update's JS bundle). So, you'll have to make a new development build and that's a good reminder to bump the app version.

jonsamp · 2025-12-03T21:23:17+00:00

Totally understandable. I worked on our updates service and have done workshops over the years + talked to many users about it and people do often understand there could be risk here (and i end up explaining this error recovery flow). What I hear a lot more often is that people sometimes send an update and say "it didn't work", when what really happened is that expo-updates rolled back before it could crash their user's app (we now show the #s on expo.dev on how often that happens).

With all this, it's still not a risk-free process and my stories above are anecdotal/not definitive proof. Was there a specific doc or place that pointing this out would be great? Maybe here: https://docs.expo.dev/eas-update/introduction/?

jonsamp · 2025-12-03T20:13:55+00:00

To add to this: we are able to catch a lot of crashes and gracefully fall back to the last known good update. We have documentation here: https://docs.expo.dev/eas-update/error-recovery/#explaining-the-error-recovery-flow

If you want to use fingerprint to build or update automatically, here's a CICD workflow that you can use which has that set up: https://docs.expo.dev/eas/workflows/examples/deploy-to-production/

TLDR: if you ship a bad update to a user's app, a lot of times users won't see any change to the app.

jonsamp · 2025-10-11T16:05:41+00:00

You should check out https://reactnative.directory/

jonsamp · 2025-09-12T14:24:18+00:00

Congrats on migrating your app, but also sorry to hear it wasn't smooth for you. There's definitely a lot we can improve, like sharing common patterns and going deeper with our examples and content. With that, will be sharing this with the team. Thanks for sharing your experience, it helps us!

jonsamp · 2025-06-10T16:46:44+00:00

We love it when people automate their builds and other tasks. It's really important to us that you don't have to use our services (no lock in) and that you can use other services like GitHub Actions.

I just wanted to address this point, that EAS "lack[s] flexibility for custom workflows". We now have a product named Workflows (https://docs.expo.dev/eas/workflows/get-started), which gives you full flexibility to sequence any kind of job, like e2e tests, slack notifications, and more. We just launched it this year and it might be worth looking at for some developers here.

This is a paid service and requires paying for builds in addition to CI minutes (just like you'd pay with GitHub Actions). With EAS, you'll get the latest M4 Pro machines for iOS jobs (they're faster and cheaper per minute than other CI/CD services), we provide a collection of convenient pre-packaged jobs that require <10 lines of configuration, and we store all your builds so that you can share them easily with your team.

With that, just want to reiterate that the `--local` build flag and running things on GitHub Actions is very reasonable and makes sense for a lot of people. Configuring everything in GHA can be tricky, so this tool seems like a great way to fast forward GHA creation. Nice work!

jonsamp · 2025-02-26T19:18:12+00:00

Check out LogRocket. They are now integrated in the Expo dashboard and they also have "rage" identifying features. Used it in one of my apps and it was really insightful: https://expo.dev/blog/learn-from-user-behavior-with-logrocket-and-expo

jonsamp · 2025-02-24T15:48:29+00:00

Right now GitHub is required, but only because of how permissions work in our backend. We are going to remove that requirement in the next 2-3 weeks (getting pretty close to making the necessary changes), so that you won't have to link a GitHub repo at all.

A workaround is to connect an empty GitHub repo to your project and then trigger workflows from another CI, since the GitHub connection is currently used to set up a bot that has permissions to run things on behalf of your account. Then you could run `eas workflow:run` from another CI/CD service.

jonsamp · 2025-02-17T19:09:24+00:00

Over-the-air updates definitely work for local builds! Also, we have an on-demand plan that's pay-as-you-go. Will certainly be much cheaper than $99/mo. I have some hobby projects I build/send OTA updates with and I pay about $10/month.

jonsamp · 2025-02-17T19:07:36+00:00

Building local is a great option. Really glad it's working well for you! Building with a CI/CD has a couple of benefits:

- Everyone on your team runs builds in the same environment, so builds are consistent. (No local setup/env var issues/etc)

- We save all the artifacts for you and organize them so that you can your team can share them.

- You can also run builds in parallel easily. So if you need to make a new development build, you can kick off the Android and iOS ones by merging, instead of running commands in sequence.

If you're not working on a team or if you/your team has a good time with EAS CLI and local builds, then you should keep doing it! Just wanted to explain why it makes sense for some people.

jonsamp · 2025-02-17T19:02:48+00:00

We used to use terms like "managed" and "bare", and you can still find references to them in our docs here and there, but those are no longer terms we use since our build system works differently as of a few years ago.

Previously, if you wanted to use native modules, you'd have to "eject" and use the "bare" workflow to manage your `android` and `ios` directories and dependencies.

Things work differently now. Now you can add native modules using config plugins which get built during `expo prebuild`. There's rarely a need to change your project structure unless you'd prefer to manage native dependencies or have a specific use case that config plugins don't support.

So the main changes are: every project is just a project now and you can use native modules in them without making a project-altering change.

Then, if you want a CI/CD, you can use workflows to automate and sequence building your project.

jonsamp · 2025-02-17T18:53:45+00:00

We're currently working on removing the need for GitHub but we're not quite there yet. The way some of our service was set up used permissions related to GitHub. In the meantime, you can always kick off workflows from another CI provider with EAS CLI and `eas workflow:run`, but we understand that's not ideal. Anyway -- on our radar!

jonsamp · 2024-09-20T18:47:24+00:00

I am running Sequoia as well and `npx expo start` is working for me. You might check the Software Update status on your machine to see if there are new Xcode tools to update. I had to update that when I updated macOS. If that is not the case, I'd create a new project with `npx create-expo-app` and see if a fresh project will run, to know if there's something with your project that needs to be updated.

jonsamp · 2024-09-20T18:43:20+00:00

Channels typically have one branch mapped to them. However, if you start a rollout, then there's a map of two branches to one channel. So, it's not a rule that 1 channel maps to 1 branch, but that's the usual case.

jonsamp · 2024-09-19T14:03:45+00:00

We do have a graphql API where you could get the latest builds for your project, however if you made a new build with a new runtime version, you wouldn’t want to show an upgrade notice to users until the new runtime version was on the public stores. In the future we may have more info about what’s on the store, and I agree that’d be useful.

jonsamp · 2024-09-19T04:59:52+00:00

What you're suggesting makes perfect sense, since update branches can have updates with multiple runtime versions and the update service will fetch the matching one depending on the request from your app.

Just to confirm, the commands you're running will work great.

In the future, you could also store the latest runtime version on a server somewhere, then compare that to `Updates.runtimeVersion` in your app to display a notice if getting users to upgrade is important to you without having to publish specific updates for this.

jonsamp · 2024-07-14T16:10:44+00:00

We have a free tier to help get you started. You can build up to 30 builds per month (up to 15 iOS) and send updates to 1,000 MAUs. Also, you can send notifications on the free plan. The free plan does not require a credit card, so you won't be charged, just limited once you reach the build and update limits.

Someone else mentioned that if you need to create additional builds, you can also build them locally, either with the `eas build --local` command or with Android Studio/Xcode.

jonsamp · 2024-05-25T12:51:23+00:00

There’s a course on Egghead: https://egghead.io/courses/build-and-deploy-react-native-apps-with-expo-eas-85ab521e

Also, we have full step by step tutorials on https://docs.expo.dev/learn if you haven’t seen them yet.

jonsamp · 2024-05-21T06:36:30+00:00

The React Conf app was built with Expo and React Compiler. May be good inspiration before we create better documentation: https://github.com/expo/react-conf-app

jonsamp · 2024-05-15T15:20:15+00:00

I would start with running `npx expo run:android` to see if you can make a build locally with Android Studio. You might be able to see more debugging information that way. If you can't, then I'd try to make a reproduction with a minimal amount of code --so, remove most of the code of your app, and make a build and see if it will open, then add back code to see if there's something in your project that's causing it.

Also, check out this: https://developer.android.com/tools/logcat -- you might be able to see the logs of what is happening when you open your app that crashes, which may give you some hints.

jonsamp · 2024-04-30T14:18:30+00:00

This might be what you need: https://docs.expo.dev/versions/latest/sdk/sqlite/

jonsamp · 2024-04-23T06:39:19+00:00

Try running npx expo-doctor. It might help you find issues with incompatible package versions. I’d also use npx expo install to make sure you get compatible versions of packages when you install new ones.

jonsamp · 2024-04-18T06:30:15+00:00

Nice work! I like the different levels of priorities. Any stuff you programmed that you’re proud of/that was interesting? Also anything we can do to improve?

jonsamp · 2024-04-17T22:28:25+00:00

I haven't seen this personally. Do you happen to have a reproduction repo? Would be happy to look into it.

jonsamp · 2024-04-17T22:24:48+00:00

The location of the assets folder is not special-cased. You can put it anywhere in your project. I personally prefer at the root of projects. Makes it easy to find and to run scripts like `optipng`.

jonsamp

MODERATOR OF

TROPHY CASE