sdk 43
eas-cli/0.36.1 darwin-x64 node-v12.13.0
using managed workflow
I do not have any env fields used in eas.json
I built a new binary with eas build and submitted it to the Apple App Store using eas submit
I then downloaded the new app, and confirmed that it was the new version.
I then published an update using expo publish
When I re-opened the app, it crashed.
I called expo publish:rollback
The app still crashes
If I delete and re-download the app, it then works well. However subsequent expo publish will break it again, so I have no way to publish updates
I found a comment in this forum saying that you need to publish at least one update before downloading the app, to avoid this crash.
So I delete the app from my device
then publish an update
then re-download the app
The app works.
Subsequent updates also work.
This seems like a very very important piece of information to have, and is not mentioned yet in the docs.
How can I rollout a new app version in this way? If any user downloads my app, before I notice it has been rolled out, and then I publish an update, they will have a corrupt app, which cannot be saved by expo publish:rollback.
It turns out that all the app in deployment are now broken.
rollback doesnt fix them.
Apple doesnt allow to rollback a binary, so I have to submit a new build, i guess, and everyones apps will be broken until then!?
please help if anyone knows a solution!
thanks 
hi there. please share a reproducible example. my first guess is that you depend on some environment variables with in your build profile, and you don’t set those locally when you run expo publish, because this is a common mistake. Environment variables and secrets - Expo Documentation
also see Troubleshooting build errors and crashes - Expo Documentation
I do not use any env vars
i do have
"hooks": {
"postPublish": [
{
"file": "expo-error-log"
}
]
},
which is the only unusual entry in app.json
eas.json is unchanged from what was generated for me
let me know what you find after going through the troubleshooting guide
I have gone through it carefully
I don’t have any way to get logs or crash data. I don’t have xCode, and the app crashes on the Splash Screen, so no errors get logged to my logging service.
if I could just FULLY rollback the expo publish to the original release, maybe that would save me for now. I can’t find a way to do that though, expo publish:history only seems to go back as far as the first expo:publish, not to the release before that, the one that was associated with the original build sent to the App Store. If it did, I could do expo publish:set
To reiterate, the App worked perfectly until I published an update with expo publish
Deleting and re-downloading the App at that point, fixes it, and everything works great.
The issue is that users will all have to delete and re-download the app now, in order to restore it, and this is not ideal.
you don’t see any crash logs in xcode organizer?
does it also crash on android / can you check on the play store console?
The issue is that users will all have to delete and re-download the app now, in order to restore it, and this is not ideal.
this is currently not handled by expo-updates. if you publish an update that is incompatible with your standalone app and it causes it to crash on startup, you will need to either have users uninstall the app and reinstall as you described, or you can publish a new build to the app store that resolves the issue. the expo-updates team is aware that this isn’t ideal and is working on a more graceful way to handle such scenarios.
charging my android as we speak
Why would my published update be incompatible?
I got a fresh version of the App, which I had just released, it worked, published an update, it broke. I didn’t install anything new, change any config, and only added one line of code.
it can’t be coincidental that if I now publish an update, THEN re-install the app, everything is fine
it’s impossible for me to say why because i don’t have your app in front of me (i also do not have bandwidth to look at it), but there are truly an infinite number of possible ways that you could have changed your code that would cause the app to crash.
it can’t be coincidental that if I now publish an update, THEN re-install the app, everything is fine
it sounds like you have the default update loading behavior set, which means that the update is downloaded asynchronously in the background when you start up the app, and the bundled embedded at build time is used on first launch instead. when you close and reopen the app, the update is applied.
does eas treeshake the builds?
I installed @stripe/stripe-react-native, and then ran the build and submit, but it was never imported in the JS files.
The update that I published imported isApplePayAvailable() and displayed the results, which worked perfectly in Expo Go (false of course)
could this be the issue? If it tree-shaked out the @stripe/stripe-react-native lib, then I could see it crashing for sure
eas build will only include libraries that are in your package.json at build time. it doesn’t matter if it’s imported in js or not. in other words, the behavior is the same as autolinking in react-native.
make sure you follow instructions for configuring stripe as described in the docs: Stripe - Expo Documentation
working in expo go doesn’t always mean it’ll work in your standalone build. this is impossible to accomplish in some cases like stripe or react-native-maps, where those libraries are dependent on configuration in your standalone app in order to work (and we just provide placeholder values in expo go, which will only work with that specific bundle id / package)
to get the most close-to-prod experience in an expo go like app, you can use development builds: Introduction - Expo Documentation