expo: Updates.reloadAsync() crashes if called during first startup
Minimal reproducible example
https://apps.apple.com/tt/app/rideswup/id1573481198
Summary
Just noticed this behaviour now. I use reloadAsync to reload the app on account removal / logout, to make sure there’s nothing left in the app’s reducers. It seems to crash only the first time app is launched. Secondary startups of the same app with no actions taken in between, don’t crash.
It’s quite hard to give a reproducible example since this only happens in the production builds. You can however just download one of our apps here, and you can clearly see the app crashing when you try logging out for the first time, after logging in (during the first launch, but not on subsequent app launches).
Android does not seem to crash, so … not sure what’s causing it in the background, but the code is literally the same in between the two platforms.
So, it is obvious something happens on iOS, with the reloadAsync method on the first launch. I do see someone “solving” the issue by disabling Hermes on iOS only (even though user states issue is present on iPads only, even though, I guess it’s literally the same build (iOS, not iPadOS) just with tablet support).
LATER EDIT Upon further checking, I can say that the crash does not happen (on initial app launch) if you call it as follows (while you have an update available:
- checkForUpdateAsync
- fetchUpdateAsync
- reloadAsync
However:
- Calling it directly, outside the context of applying an update, it does crash.
- Also calling it, after applying an update and triggering
reloadAsync, app reloads fine. If you however call it (just like before, directly, outside the context of applying a proper update, it does crash.
So, it seems it does not matter whether the app was previously reloaded properly with an update, as long as it’s the first app launch. Restarting the app once then calling reloadAsync, does NOT fail.
You can however see that there are quite a few people reporting the same (or very similar issues), after a quick search.
https://github.com/expo/expo/issues/19812 https://github.com/expo/expo/issues/17702 https://stackoverflow.com/questions/71600883/expo-update-reloadasync-crashes-app-in-release-build https://stackoverflow.com/questions/70785635/expo-ios-app-is-crashing-when-fetching-for-new-version https://forums.expo.dev/t/eas-update-expo-updates/62708 https://forums.expo.dev/t/upgrading-from-sdk45-to-sdk47-makes-updates-reloadasync-crash-app/69343 https://forums.expo.dev/t/updates-reloadasync-crashes-first-time-then-work-but-update-is-not-applied/69438 https://forums.expo.dev/t/reloadasync-crashes-app-in-release-build/62643 https://forums.expo.dev/t/out-of-memory-crashes-freezing-on-programmatic-ota-updates/65718 https://forums.expo.dev/t/expo-updates-crashes-the-app-on-ios/51472
Please advise
Environment
expo-env-info 1.0.5 environment info:
System:
OS: macOS 13.2.1
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.18.1 - ~/.nvm/versions/node/v16.18.1/bin/node
npm: 8.19.2 - ~/.nvm/versions/node/v16.18.1/bin/npm
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
IDEs:
Xcode: 14.2/14C18 - /usr/bin/xcodebuild
npmPackages:
expo: ^47.0.6 => 47.0.13
react: 18.1.0 => 18.1.0
react-dom: 18.1.0 => 18.1.0
react-native: 0.70.5 => 0.70.5
npmGlobalPackages:
eas-cli: 3.6.0
expo-cli: 6.3.1
Expo Workflow: managed
About this issue
- Original URL
- State: closed
- Created a year ago
- Reactions: 3
- Comments: 55 (18 by maintainers)
@edi @Inspiravetion - I will be investigating this and attempting to reproduce in-house. In the meantime, the comment above by @brentvatne is valid. If you do have a small project that does not have a large number of dependencies, and reproduces the issue, it would be really helpful. I do appreciate all the details that you have shared so far (e.g. the steps described in https://github.com/expo/expo/issues/21347#issuecomment-1441009063)
I am still seeing this issue on Expo 50 on Android running Hermes. The call to Updates.checkForUpdateAsync() is hanging.
I can confirm the same issue, after
reloadAsyncif you callcheckForUpdateAsyncit doesn’t resolve or rejects. The problem with timeout @webdevmario @ilyausorov is that looks like in different mobiles happens at different times, so 3 seconds won’t always work. What I did is simply create a timeout aroundcheckForUpdateAsyncand you can retry if it didn’t finish or just ignore:I have to say that I tested the next versions of expo-updates coming, with
useUpdateshooks and everything worked really well without workarounds. It should come with Expo sdk 50 so shouldn’t take a long time.Hi. As a workaround, you can either switch to Hermes instead of JSC engine, and if that’s already the case, you can upgrade to SDK 48, which does that for you anyway.
The issue doesn’t seem to exist in the new version, tested on all apps, small and big.
+100 to this…I have been seeing this ever since I upgraded from 45-47 almost two weeks ago and have gotten no response on the forums despite seeing more and more people reporting the same thing…for me the scenario is as follows:
eas update --branch $_ENVIRONMENT --non-interactive --message $_RELEASE_IDSplashScreen.preventAutoHideAsync();is called in the global scope before the app is rendered and stores start to loadappUpdateStore().init()runs (before the splash screen is unlocked)5a. on iOS: app crashes at
await Updates.reloadAsync()5b. on Android:await Updates.fetchUpdateAsync()hangs indefinitely 6. opening the app after the crash/hang updates like normal (on the first try if the update finished downloading, otherwise it takes two open/closes for android)For context: I am building on EAS with a paid account and had no issues around this before 47 or any other problems upgrading to 47.
eas.json
app.config.js
package.json
@ewein & @billyhawkes I had this problem too (you can see me commenting on this issue some months ago). I haven’t had any problem with the new hooks API (I really think the old way is broken). Not your fault since the docs aren’t very clear about how to use it. Here’s my implementation and, hopefully, you make it work:
Hello, I’m able to reproduce this crash on SDK 48 and SDK 49. My crash occurs when restarting the app after changing its language.
The crash happens when using the Updates.reloadAsync() function to restart the app. I have similar behaviour with the use of react-native-restart…
I created a blank project on GitHub to replicate the issue, but no crash occurred in this context, upon further analysis, I noticed that animations were active at the time of calling Updates.reloadAsync(), specifically a “bounce” animation from reanimated.
I reduced the duration of the animation to 250 ms and I added a delay before executing Updates.reloadAsync(). These changes prevented the crash in my tests.
I suspect that restarting the JavaScript bundle during an animation with reanimated might be causing the issue. I am not 100% certain that this solution definitively resolves the problem 🤷♂️
haha, you’re welcome! ¯_(ツ)_/¯ good luck making a minimally reproducible example for something like this. Sometimes you just gotta fix your own app and move on
Very interesting! Since the problem is fixed in SDK 48, I will create an engineering task to investigate this and see if there are any patches that we can safely backport to SDK 47 to fix this issue. Of course, we obviously prefer that you move to SDK 48 😄
I can confirm, it’s only SDK 47 with the issue. Just upgraded to SDK 48, made a new build, ran
Updates.reloadAsyncon the first app launch, didn’t crash.Reproducing this is as easy as it gets. Make a blank new app, (SDK 47) install
expo-updates, make a simulator build, trigger thereloadAsyncmethod on the first app launch, it crashes. Re-open the app, trigger the same method, doesn’t crash.You don’t need any pushed updates, nothing. Simply calling
reloadAsyncwith the first launch of the app, causes it to crash, while on subsequent app launches, it doesn’t.@douglowder @brentvatne here is the repo. It doesn’t get to call
reloadAsync()because the call tocheckForUpdateAsync()never returns that one is ready.to test:
yarn run buildyarn run update@douglowder i will create a clonable repo so you can test, but basically, just thi (on mobile now):