John Bacon | Software Architect @ Words With Friends
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.
- 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
Solution — Bugsnag
- Native SDKs power their React Native library under the hood, allowing us to continue to capture native crashes as well
- Robust Indexing enables powerful search functionality which improves the efficiency of resolving stability related issues
While the workflow for monitoring and fixing crashes with Bugsnag is fairly standard, the goal for us was making sure we could achieve the same workflow on React Native with equal or better efficiency:
- Monitor our crash inbox daily
- Identify trends to see crashes rising (or falling)
- Select a crash which we intend to fix
- Analyze the source file and line number
- Fix the crash, or notify a partner team if not originating in our code
- Release an update with the fix
- Monitor to see if the crash has disappeared
- Sentry is a competitor of Bugsnag and provides a powerful alternative, but their library for React Native is labeled as a beta release so we were leery about relying on it
- User-Based Trend Graphs are not yet part of their offering, but they may provide similar functionality in the future, and integrations such as Splunk allow us to create something similar ourselves. Being able to see what percentage of users are crashing on any given day is something we find extremely valuable.
- Shareable Public Crash Links are not supported, but they do have a new feature to export a crash dump that can be shared out. When crashes do not originate in your code, being able to share crash reports with partners without giving full access to your crash reporting tools is very valuable.
- SDK Conflicts have been an issue, since Bugsnag has had less time than other native crash reporters in the market to become battle tested with the huge variety of SDKs we use on Words With Friends — for example it had issues initially running in parallel with one of our ad networks that was also reporting on crashes
- Pricing Model is event based, so we implemented sampling of non-fatal (handled) errors to make sure we are recording events judiciously
There are some nuances with how to setup React Native and Bugsnag in order to get the most out of your integration. We learned through a few iterations how to make sure we were getting the most accurate stability reporting.
Get the Most Out of Stability Scores
- Manually start a Session as Soon as the SDK Starts to make sure you capture the session before the app could crash, resulting in the most accurate stability scores
Leverage the Splunk Integration If Possible
With the Splunk integration, you can stream crashes in realtime and cross reference Bugsnag data with other data you’re already capturing to generate custom reports. We have found this integration valuable to build out some of the reporting features we miss from other native crash reporters like the aforementioned user-based trend graphs.
- Android JSC BuildScripts is an open source library that allows developers to take a newer version of JSC on Android without having to wait for React Native to upgrade it — we used this and our line numbers started working right away (we were on React Native 0.58.6 at the time)
- Upgrading to RN 0.59 includes the new JSC, so if you’re on 0.59 or higher, line numbers should work from day 1, though the open source library provides flexibility for future updates when the developer would like if the need arises
Leverage the Fact that Bugsnag Libraries Are Open Source
- Easy to see new changes which helps identify the risk of taking a new version of their library
- See if your issue already exists as an issue on the relevant library’s repo, and upvote an issue you too are seeing to help escalate priority
- Understand an issue you are facing since you can step through their source code while debugging an issue