well I’m very confused then. Here is the quote i found that made me think there was a step I was missing 
Does this mean that I need to run expo publish --release-channel staging before I run eas build? I dont currently use release channels at all in my work flow, so this isnt part of my routine
in that specific issue the developer was using Constants.manifest.releaseChannel, which is only available if you are loading from an update (not from an embedded bundle). so, in order for that to work, he had to publish to make apps load a new update and have that field be available. we don’t recommend using that field, you should use Updates.releaseChannel instead. this seems unrelated to what you are experiencing
Ok I think I know what happened.
I updated to SDK 43, and ran eas build and submit with v17 of my app.
No issues because expo-publish knows not to send users updates across SDKs
Next I installed @stripe/stripe-react-native, and ran eas build and submit with v18 of my app
No issues because updating the App gives the new binary with the libs installed
Next I ran expo publish
Big problem because now users with v17 installed, with SDK43, WILL receive these updates, but if they havnt updated the App, then they dont have @stripe/stripe-react-native, so app crashes
1 Like
that sounds right. i’d recommend referring to the updates guidance on the eas section for more info on how to handle these kinds of deployments: Using EAS Update - Expo Documentation
we’re in the process of working on EAS Update which provides better answers out of the box for this
Wait that doesn’t even make sense, because I installed v18 on my phone, which is SDK 43, and has @stripe/stripe-react-native, and then ran expo publish and the app crashed!
So I had a compatible binary, and it still crashed.
This seems like a bug to me! Sorry if I’m missing something and making a fuss over something that’s just my own oversight! I’m just here reporting what I see as a bug!
I want to do my due diligence in case others have to experience this!
For now, submitting a new build through the App Store, and waiting for eas update seems like my only course of action, which is pretty problematic unless it is close to the release date!
it’s quite possible that, as i pointed out above, @stripe/stripe-react-native wasn’t properly configured. i do not know what failure mode that library has in the case that you try to call into, eg: isApplePayAvailable() when the expected configuration hasn’t been set
I’m sorry that doesn’t make sense to me because the published update works perfectly after re-installing, and works perfectly in expo GO. It returns true on my phone where Apple Pay is available. The only issue I have seen is that after the first expo publish after downloading the new binary, it crashes. re-install the app and everything works right. This seems fishy!
I think “re-install the app and everything works right” is a red herring. That just means that your app was in a good state at build time and isn’t when you publish.
If you can identify a good state before you added stripe, you can fix things for users without submitting a new build: Advanced release channels - Expo Documentation
If you need to add new libraries within an SDK version, you can use run time versions Runtime Versions - Expo Documentation to make sure you only push updates to compatible builds.
This build was the last reliable one.
If I try to use the build ID with expo publish:set it doesnt work.
When i use expo publish:history only the last 4 updates are listed.
how can I access the piblish ID from this build so I can use publish:set ?
sorry just discovered the --count flag.
It turns out I didn’t expo publish during the window when I updated to SDK43 and released the good binary, and when I added stripe, and released a 2nd binary, so publish:set cant seem to help me. If I could revert to the version that was present with the app store release that would be great, but since I didn’t run publish it looks like I can’t?
I have uninstalled the Stripe library and removed the Stripe Plugin, and published a new update with expo publish. I hope that works?
once this settles out I will try again using the Runtime thing, that looks very helpful. I shouldn’t have skimmed that in the docs before launching into eas
also regarding the red herring:
Its not just that re-installing fixes the app, it’s that re-running the same update after re-installing, and any subsequent updates, works fine. The only time the issue crops up is the following edge case:
A binary is downloaded from the App Store before any updates have been published
And then an update is published.
This incurs the crash
This is the edge case that any users are in, who updated their app via app store, before I had a chance to publish an update via expo update.
this incurs a crash even in compatible binaries, or so it seems to me.
You’re welcome to examine my now very convoluted build and publish history if you like. I truly hope nobody else experiences this, and that it is somehow my error!
if you believe it’s a bug, please file an issue and provide a reproducible example. i’ve tried my best to answer here what i think is the issue, but without a minimal reproducible example and it’s hard to help much more. good luck!
I’ll keep my eyes peeled and if anyone else has the problem I’ll try to make a reproducible example.
For anyone googling this, what worked is:
yarn remove @stripe/stripe-react-native
erase the plugins array from app.json
remove any imports and uses of @stripe/stripe-react-native
expo publish
I suspect if my files and commits were in better order then a faster approach would be:
expo publish:history --count 50
find the last working update from the list
expo publish:set --release-channel default --publish-id <the-last-good-publish-id>
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.
This comment doesn’t seem to be accurate, and was partly the cause of my extreme concern. Maybe it would be a good idea to clarify or remove the comment? expo publish:set did indeed fix the situation