Does crashlytics able to de-obfuscate the obfuscated error for react native (JS) app?

[vinothst]

I am working on a React Native app that uses Firebase Crashlytics for error reporting. My app is built with JavaScript (using Hermes), and I am attempting to deobfuscate JavaScript errors in the Crashlytics dashboard by uploading the source map generated during the release build process.

However, after trying multiple approaches found online, I’ve encountered the following challenges:

Source Map Upload: The official Firebase documentation mentions uploading mapping files for native apps (e.g., ProGuard mappings for Android or .dSYM files for iOS) but does not clearly describe a process for uploading JavaScript source maps in React Native.

React Native Compatibility: The firebase crashlytics:symbols:upload CLI command appears to be designed for native symbol files and results in errors when attempting to upload the JavaScript source map (e.g., Breakpad symbol generation failed).

Deobfuscation in Crashlytics: Despite generating the source map (e.g., index.android.bundle.map), I cannot find any documentation or steps in Firebase Crashlytics to support its upload or ensure deobfuscated stack traces in the dashboard.

Request for Clarification:

1. Does Firebase Crashlytics currently support uploading JavaScript source maps for React Native apps?

2. If supported, what is the correct process for uploading the source map to enable deobfuscated stack traces in the Crashlytics dashboard?

3. If not supported, are there any future plans to include support for JavaScript source maps for React Native apps?
   I would greatly appreciate your guidance on whether deobfuscation for React Native JavaScript errors is achievable in Firebase Crashlytics, and if so, how to implement it.

Thank you for your time and assistance!

[mikehardy]

No crashlytics cannot deobfuscate javascript stack traces.
You'll have to save your mappings (from typescript -> javascript if you use typescript, and for whatever steps you do to bundle/minimize)
You'll need to have a utility handy that you can use to paste the obfuscated stack in that will decode it

I do something similar with native java minimized code where google doesn't have the mappings. On macOS you can use pbcopy and pbpaste utilities to work with your clipboard in a small shell script. If you have your mappings local then you pbcopy in the shell script, send the trace through your deobfuscation utilities using your locally stored mappings, then pbpaste it back to the clipboard. Now you can put that trace into your IDE or an issue tracker or where ever you need it

[vinothst]

Thanks for your confirmation and also for your suggestions, much appreciated.
Just one more follow up query.
I have tried with Android and raised the question. I am also checking with iOS now. Is your answer applicable for iOS as well?
FYI, We use react native for both Android and iOS.

[mikehardy]

javascript (or typescript, if you use it) is javascript. same applies for javascript stack traces that are logged by crashlytics
a native crash is a different thing entirely but those are pretty obviously different as native stacks on iOS (or Android) are pretty clearly not javascript - very easy to identify as not in your javascript application code. Those are the sorts of things you would typically log with whatever module showed up in the top frames of the stack trace, and the mappings (dSYMs for iOS, proguard mapping files for android) are typically handled by crashlytics assuming you have uploaded them (which should happen by default if your build system is configured well but it is build system dependent...)

I recommend testing it versus just wondering how it looks / if it is working etc:

You can test a javascript crash with information from https://invertase.io/blog/react-native-firebase-crashlytics-configuration#testing-your-configuration

You can test a native crash by calling the crash() method https://rnfirebase.io/reference/crashlytics#crash

[vinothst]

Got it, Mike. Tried this already. Thank you!