Let’s imagine that my application has been accepted on the Stores and that, some time later, I have an update to perform on this same application.
Should I submit a new build ? Or is EAS update sufficient?
I’ve gone through the documentation and researched all over the place and can’t find an exact answer to this question.
Also, EAS update doesn’t seem to work (in dev mode).
Thank you in advance for your help
- if you submit a new build, users will have the latest version as soon as they download it from the store
- if you only publish an update, then users will download that depending on how you configure your update policy. the default is to download it in the background after the app launches. so, the first run after download will have the ‘embedded’ update in the app on the store, and then the next launch will use the update.
Nobody cares ?!
to file a support ticket to be triaged by the support team, you can use this contact page. it factors in any subscription you may have (production/enterprise) and guarantees a response within the appropriate windows. support on forums is provided as-is and mostly done through the community, but expo team members like myself try to help when we have some spare time as well.
In addition to what Brent said, the answer to this question depends…
You should avoid making big changes using EAS update. Basically it should normally be for bug fixes rather than new features.
Also, an update will only work if the underlying native code is still compatible. So if you need to add a dependency that includes native code, then an update won’t work. See Runtime versions and updates
e.g. if you set your runtime version policy to
appVersion and forget to update the app version after installing a new native dependency, and then publish an update, then when the user’s existing app tries to run the code that references the new native code, it will crash, because the native code does not exist in that version of the app.
See also How EAS Update works
It should, but e.g. if you’re using an old development build with an incompatible runtime version then the update will be ignored. See Using expo-dev-client with EAS Update and also Debugging (Note that if you use
npx expo prebuild while debugging, you’ll want to commit all of your changes to Git before running
prebuild because it generates the native projects and makes some other changes to
package.json etc., so you’ll need to revert those changes after you’re finished troubleshooting. e.g. see expo.fyi/prebuild-cleanup)
If you can’t get it to work, please elaborate on exactly what you’re doing, step by step, and what you expect to happen and what happens instead.
You should probably read through Deployment patterns as well.
Hi @wodin @brents
Thanks for your precisions. I needed it for both technical and practical reasons. I have already had the opportunity to submit applications on the Stores as well as to update them but never with EAS.
Rest assured that I always read the documentation and consult all sorts of resources on the Internet before posting anything on a support forum.
Now I’m sure I know what I’m going to do or not do before I submit my first build with EAS. What is expected soon.
Thank you again for your answers !
This is just my opinion, and it does totally depend on your application, it’s release cycle, and your users…
But generally speaking nearly every time I go with… BOTH!
We want most users to get the latest updates immediately from eas update, but we want the first install from App store to be up to date too as soon as the is app review passes.
Both is the way to go for most cases, then occasionally, like a major update or a runtime version change, will be build only.
And sometimes for a small version specific bug we do only an update. These are the main fringe cases.
You might find things different if your app has a long release cycle, or all kinds of variable to do with users. But my advice is try for both
Yes absolutely. You’re right @brooke.mitchell-ez
It will definitely be both!