It provides JS errors to be pretty easily shared to analytics. What is missing is getting visibility into Native Errors in production while continuing to give Expo team visibility. I know I can config exp.json to point away from the default. But I’d love to keep sharing data to Expo while also having visibility into the health of my user base.
Getting visibility to these native crashes IS actionable. Perhaps I can repro and disable the feature OR I’m slowly rolling out some redesign and I want to stop the roll out OR I can proactively reach out to users who have encountered an issue. There are many actionable insights I can make if I have visibility into native errors. It would provide at very least a basic peace of mind.
Hi! You make a great case. At this point we are limited by the mechanics of Fabric, which assumes:
(1) It must upload native debug symbols at build-time,
(2) Only one Fabric account should be the recipient of these symbols.
As far as I know these assumptions hold for their competitors as well. #1 is not a limitation for us on Android, which is why we let you provide custom Fabric keys there. #2 is a limitation on both platforms.
If there’s a particular native crash you’re wondering about, it’s often worth asking in Slack if we can go check it out for you. The vast majority of the crashes will be a variation of this:
This is the category mentioned in the docs article as well, where a JS symbol came over the bridge with an unexpected type or the wrong bounds, and gets stuck in RCTConvert.
Is it possible to pump the native error into JS on next launch? Eg store the crash info at crash time and read the info on next launch.
Also with the convert crash your mentioning is it possible to get some JS context of the native crash? Eg knowing the JS stack that passed the bad value into native bridge?
Possible to call into JS at crash time? Thinking then we could store some current state so that we know what the user was looking at during crash.
(1) The crash report would be unsymbolicated, just a bunch of addresses, so probably meaningless. That’s why Crashlytics requires debug symbols.
(2) Currently, no. All of the native stack traces will begin with a generic invocation from the JS-to-native bridge, without information about the JS stack.
(3) This is an interesting idea. I’m not confident it would work but it seems like it might be possible. I’ll make sure we look into the idea in an upcoming cycle.
I think that would be fine since we could send the crash info along to whatever service at that point and provide that service the symbols as well. This way expo can continue getting crash info as well as us get analytics on it.
