React Native Stability Monitoring
--
John Bacon | Software Architect @ Words With Friends
Background
Back in the fall, we announced that Words With Friends is transitioning the majority of its codebase to React Native. In that article, we talked about how we are A/B testing the React Native pieces against their native counterparts to ensure the transition does not negatively impact game health. We also talked about how we’re using Bugsnag to monitor crashes and app stability. In this article, I want to talk about how we’re able to maintain the same quality of stability monitoring in a React Native world as we had with a fully native app. Bugsnag has been a vital tool to support our stability workflow throughout the transition process that has enabled us to iterate quickly on issues we were not able to catch in house.
Problem
- Crash Analytics is a vital tool for understanding, improving, and maintaining the stability of apps
- Symbolication of crash reports allows these tools to tell engineers where in the code the problem lies
- React Native Crash Reports in native crash reporters contain a minified and obfuscated JavaScript call stack that is hard to action on
In a native crash reporter, a React Native crash report from an unhandled JavaScript exception looks as follows:
We do get a call stack, but it is the call stack for the native exception thrown by React Native. JavaScript does not crash, but when an unhandled JavaScript exception occurs, React Native throws a native exception that causes a crash. While these reports are still useful for tracking the volume of crashes coming from JavaScript code, it’s not immediately actionable like a typical native crash report. The JavaScript call stack is all part of the crash report message, and is also minified and obfuscated. Further, all crashes from unhandled JavaScript exceptions are grouped together because these exceptions all have the same native call stack, making it hard to see how many different issues we have.
