So this is an example of the “Update prompt” UI I built that used but of course you need to be loading my app for the Updates to come through:
- Testing on live devices with live app store app.
- I did set app.json to updates on error recovery, but I have yet to upload the new app to the app store.
First time I published, I created an endless Upload.reload() loop because it simply thought there was a new update every time the app reloaded.
Then I rolled back with publish but the thing is, the app never updated. My live iPhone X device maintained the loop, it would never actually reload with the newly published rollback (removing the code in componentdidmount).
Another bizarre thing. This morning 12 hours later, another user of ours also retrieved this old publish and entered an endless reload loop. It’s like his phone had queued up the first publish I made.
The only resolution for all of us was to uninstall and reinstall the application. Only then did Expo retrieve the latest publish.
Okay so then I added this setState to create a prompt button. Maybe I thought the Update.reload() loop was causing Expo to be unable to remember if the user reloaded new information.
Well it’s still giving me update.isAvailable, so we’re alway seeing the Update button. AND it seems to be confused about which published app to serve. Sometimes it serves something I published an hour earlier, sometimes immediately.
Possibly observed behavior was also that incrementing the app.json version number more forcefully made Update.reload() retrieve the latest publish.
So all of this is on a live app (not Testflight) on now confirmed multiple iPhones and our live Android Moto-G. We’re on a quiet Beta right now so it’s not a huge problem.
It would be great to keep OTA but it’s API behavior seems a bit unpredictable. My feeling is to not even try checkAsync, and simply trigger Updates.reload() under some custom condition we write.