Some preliminaries:
- Managed workflow
- eas-cli/0.41.1 darwin-x64 node-v16.3.0
- expo: ~43.0.3
- expo-updates: ~0.10.13 (possibly relevant)
I’m still very new to Expo, so not exactly sure what I should include here.
We deploy using EAS and are currently only focused on iOS. We’ve run into an issue where all 1.0.* builds crash on the second startup; i.e. I can install any 1.0.* build using TestFlight, and it runs fine; completely functional. As soon as I close the app and restart, it crashes and will never open again. However, 1.1.* builds work fine, even though there is very little difference between the first of the 1.1.* builds and the last of the 1.0.* builds.
As a test, I pulled down the commit from the 1.0.56 build. I renamed the build and version number to 1.1.4 and pushed it up to TestFlight. This version works fine - no crashes after closing the app.
Notably, the 1.1.* builds do include a new package in package.json, react-native-svg
. If that were the problem, I wouldn’t expect simply renaming 1.0.56 to 1.1.4 to have resolved the issue.
To reiterate - literally the only difference between 1.1.4 and 1.0.56 is the expo.version
number and expo.ios.buildNumber
in app.config.ts
. Yet one functions completely fine and the other crashes.
This is puzzling.
My understanding is that EAS doesn’t publish JS updates automatically, and we currently don’t use expo publish
. I bring this up because I found something interesting in the expo-updates documentation:
If your app.json does not contain an
updates.fallbackToCacheTimeout
field it will default to0
andexpo-updates
will attempt to start your app immediately with a cached bundle while downloading a newer one in the background for future use. When using this configuration, users that download the app from a store and launch it for the first time will always see the version of the app that the binary was built against.
We do have updates.fallbackToCacheTimeout
set to 0, but like I mentioned, we don’t use expo-updates, at least not intentionally. However, the above could explain what’s going on. The version of the app that the binary was built against seems to always work on install and first use - it’s perhaps only after an update is attempted in the background and the user closes and reopens the app that the app continually crashes.
Any leads or ideas here would be much appreciated - this has been one of the most frustrating and difficult problems to debug.
Although I haven’t found it useful, I’ve included a sample crash report below.
Incident Identifier: F7A6DC05-DFB7-4626-844A-C343F355A826
Hardware Model: iPhone12,1
Process: LocalKitchens [1251]
Path: /private/var/containers/Bundle/Application/A322E09C-F475-4C3E-8027-8E0A75D0DC69/LocalKitchens.app/LocalKitchens
Identifier: com.localkitchens.guest-mobile.ios
Version: 1.0.56 (1.0.56)
AppStoreTools: 13C90b
AppVariant: 1:iPhone12,1:15
Beta: YES
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.localkitchens.guest-mobile.ios [819]
Date/Time: 2022-01-26 14:24:24.6739 -0800
Launch Time: 2022-01-26 14:24:16.2050 -0800
OS Version: iPhone OS 15.2.1 (19C63)
Release Type: User
Baseband Version: 3.01.02
Report Version: 104
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Exception Note: EXC_CORPSE_NOTIFY
Triggered by Thread: 33
Last Exception Backtrace:
0 CoreFoundation 0x1808450fc __exceptionPreprocess + 220 (NSException.m:200)
1 libobjc.A.dylib 0x19907fd64 objc_exception_throw + 60 (objc-exception.mm:565)
2 LocalKitchens 0x1021a5134 RCTFatal + 668 (RCTAssert.m:146)
3 LocalKitchens 0x1022226f8 -[RCTExceptionsManager reportFatal:stack:exceptionId:suppressRedBox:] + 600 (RCTExceptionsManager.mm:89)
4 LocalKitchens 0x1022230b4 -[RCTExceptionsManager reportException:] + 1532 (RCTExceptionsManager.mm:164)
5 CoreFoundation 0x1807ce3a4 __invoking___ + 148
6 CoreFoundation 0x1807ebb74 -[NSInvocation invoke] + 468 (NSForwarding.m:3378)
7 CoreFoundation 0x1808229d4 -[NSInvocation invokeWithTarget:] + 80 (NSForwarding.m:3475)
8 LocalKitchens 0x1021d5fa0 -[RCTModuleMethod invokeWithBridge:module:arguments:] + 460 (RCTModuleMethod.mm:584)
9 LocalKitchens 0x1021d8438 facebook::react::invokeInner(RCTBridge*, RCTModuleData*, unsigned int, folly::dynamic const&, int, (anonymous namespace)::SchedulingContext) + 540 (RCTNativeModule.mm:181)
10 LocalKitchens 0x1021d8070 operator() + 56 (RCTNativeModule.mm:103)
11 LocalKitchens 0x1021d8070 invocation function for block in facebook::react::RCTNativeModule::invoke(unsigned int, folly::dynamic&&, int) + 100 (RCTNativeModule.mm:95)
12 libdispatch.dylib 0x1804b5924 _dispatch_call_block_and_release + 32 (init.c:1517)
13 libdispatch.dylib 0x1804b7670 _dispatch_client_callout + 20 (object.m:560)
14 libdispatch.dylib 0x1804bedf4 _dispatch_lane_serial_drain + 672 (inline_internal.h:2601)
15 libdispatch.dylib 0x1804bf968 _dispatch_lane_invoke + 392 (queue.c:3937)
16 libdispatch.dylib 0x1804ca1b8 _dispatch_workloop_worker_thread + 656 (queue.c:6727)
17 libsystem_pthread.dylib 0x1f121b0f4 _pthread_wqthread + 288 (pthread.c:2599)
18 libsystem_pthread.dylib 0x1f121ae94 start_wqthread + 8