EAS Build -> Managed Workflow -> Expo Publish -> App crashes

Hey all. So if I understand things correctly when I build with eas build it uses the default release channel.

Once the app is published and submitted to TestFlight I am trying to send a minor update to it using expo publish but what happens is my app just crashes once I publish an update.

Any idea why this could be happening?

You should debug this further- it strongly indicates that your new JS has a fatal error in it that’s causing your app to crash. You can use something like Sentry to try and get more information on those errors

In the future- posting that your app is crashing and asking why is just way to general, and it’s impossible for anyone to offer any real help. You should debug your app the same way you’d debug any other code you’ve written to try and identify the root cause and fix it. We have a guide on production app debugging you can follow as well

Thanks Charlie appreciate the candid feedback. No problem with the javascript bundle, once I package and deploy through eas build again all works fine.

Just trying to ascertain whether it should work really here before diving deep as I noticed the limitations on eas build for managed workflows but there was nothing indicating this would be a problem.

heya, check out this section of the docs: Using EAS Update - Expo Documentation

this is a temporary quirk that will go away when we get closer to launching proper managed support

Ah yes that’s the problem, thanks Brent. Apologies I missed that in the docs.

1 Like

sorry about that @sensive ! I was not aware of the need for the --target bare flag when running expo publish for EAS managed apps right now

3 Likes

Is this still the case with SDK 41 - Managed Apps?

I’ve just bought EAS access as it seemed a nice solution, but my ios app (appstore as well as simulator) crashes directly on launch … so not really sure how to debug it, as it’s fine within the Expo Go client.

Regards

1 Like

this is no longer the case with SDK 41 managed apps.

Separately- EAS access won’t help you with app crashes- you should investigate the device logs and follow this guide to debugging prod app crashes

I understand though It’s very weird. I’ve just tested a simulator build with the normal expo build command, all runs perfectly on both iOS and Android.

App also runs perfectly after upgrading to SDK 41 within Expo Go client on both iOS / Android.

But when I do an EAS build (wanted that tree shaking feature which got my app from 55MB to 19MB), iOS crashes on simulator, even before loading the splash screen, whereas on Android, it crashes when it tries opening up the camera.

Again, both work just fine using expo build … so I’m pretty much sure it’s not related to the code.

make sure to follow these instructions: Migrating from “expo build”

as @charliecruzan mentioned, there is some useful debugging advice in the docs also.

also, if you have Xcode installed locally, you can run expo run:ios and it will do the same sort of build process as on EAS Build and build the app for the simulator. this command generates some other files, so once you’re done investigating, just reset to the most recent commit and run npm install again to restore your node_modules to their previous state

so I’m pretty much sure it’s not related to the code.

we’ve handled every difference we were aware of automatically where possible and otherwise clarified differences in the migrating doc. but there may be some differences between expo build and eas build we didn’t account for yet, and those could be impacting you. so let us know what you find from the above.

for example, maybe you’re using env vars in your app in some places. it could be that you didn’t add env vars to your build configuration on eas build (as described in the migrating doc), so when you run your app and it tries to access the env var then it crashes.

So I just ran into this on SDK 42:

  1. Built my app via eas build -p android and uploaded the binary to Internal Testing on the Play Console.
  2. Downloaded the app via the internal testing link.
  3. Confirm the app loads to initial screen fine.
  4. Change a Text component’s text on the initial screen slightly (no new native modules).
  5. Confirm change is reflected in my custom development client.
  6. Publish via expo publish --release-channel staging (staging corresponds to releaseChannel in eas.json)
  7. Re-opened app: instant crash.

The native logs I pulled from ADB seems to indicate something wrong with BatchedBridge:

2021-08-01 18:05:23.330 27388-27388/? D/SoLoader: libfolly_json.so found on /data/data/com.teamtopspin.topspin.staging.android/lib-0
2021-08-01 18:05:23.325 27388-27388/? W/staging.android: type=1400 audit(0.0:19306): avc: granted { execute } for path="/data/data/com.teamtopspin.topspin.staging.android/lib-0/libjsinspector.so" dev="dm-8" ino=483962 scontext=u:r:untrusted_app:s0:c165,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c165,c257,c512,c768 tclass=file app=com.teamtopspin.topspin.staging.android
2021-08-01 18:05:23.329 27388-27388/? W/staging.android: type=1400 audit(0.0:19307): avc: granted { execute } for path="/data/data/com.teamtopspin.topspin.staging.android/lib-0/libfolly_json.so" dev="dm-8" ino=537940 scontext=u:r:untrusted_app:s0:c165,c257,c512,c768 tcontext=u:object_r:app_data_file:s0:c165,c257,c512,c768 tclass=file app=com.teamtopspin.topspin.staging.android
2021-08-01 18:05:23.337 27388-27388/? D/SoLoader: libjsc.so not found on /data/data/com.teamtopspin.topspin.staging.android/lib-main
2021-08-01 18:05:23.337 27388-27388/? D/SoLoader: libjsc.so found on /data/data/com.teamtopspin.topspin.staging.android/lib-0
2021-08-01 18:05:23.509 27388-27452/? D/SoLoader: libturbomodulejsijni.so not found on /data/data/com.teamtopspin.topspin.staging.android/lib-main
2021-08-01 18:05:23.509 27388-27452/? D/SoLoader: libturbomodulejsijni.so found on /data/data/com.teamtopspin.topspin.staging.android/lib-0
2021-08-01 18:05:23.579 27388-27460/? E/AndroidRuntime: FATAL EXCEPTION: mqt_js
    Process: com.teamtopspin.topspin.staging.android, PID: 27388
    com.facebook.jni.CppException: Could not get BatchedBridge, make sure your bundle is packaged correctly
        at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
        at android.os.Handler.handleCallback(Handler.java:938)
        at android.os.Handler.dispatchMessage(Handler.java:99)
        at com.facebook.react.bridge.queue.MessageQueueThreadHandler.dispatchMessage(MessageQueueThreadHandler.java:27)
        at android.os.Looper.loop(Looper.java:223)
        at com.facebook.react.bridge.queue.MessageQueueThreadImpl$4.run(MessageQueueThreadImpl.java:226)
        at java.lang.Thread.run(Thread.java:923)
2021-08-01 18:05:23.582 1559-4722/? W/ActivityTaskManager:   Force finishing activity com.teamtopspin.topspin.staging.android/.MainActivity
2021-08-01 18:05:23.664 1559-1946/? I/ActivityManager: Process com.teamtopspin.topspin.staging.android (pid 27388) has died: prcp TOP 
2021-08-01 18:05:24.083 1559-1593/? W/ActivityTaskManager: Activity top resumed state loss timeout for ActivityRecord{b94dbab u0 com.teamtopspin.topspin.staging.android/.MainActivity t-1 f}}

So I’m not sure if this is an issue, but I also installed a native module (react-native-purchases) that doesn’t require any additional native linking besides pod install, but I believe EAS build seems to handle fine from what I can tell in the cocoapod logs.

Alright, so somehow this stopped happening, and I’m not sure what exactly changed.

It could have been one of the following:

  1. Bumped to new version code or version
  2. Some weird interaction with one of my installed modules on startup

I’ll reply again if it comes up again… hopefully this is resolved.

Ran into this issue on SDK 42. It stopped happening and then appeared again.

For people that may encounter this issue in the future, the issue in my case was caused by the combination of the following issues:

  1. Avoid relying on constructor.name for instanceOf error check. by benjamn · Pull Request #2894 · graphql/graphql-js · GitHub
  2. babel-plugin-transform-inline-environment-variables does not seem to work with react-native · Issue #687 · babel/minify · GitHub

Not sure why, but during expo publish if transform-inline-environment-variables babel plugin was present, the resulting NODE_ENV was undefined. After removing transform-inline-environment-variables everything works as expected.