Igor
A React Native bug report needs the build that was running, the device and OS, the screen the tester was on, what they did, what they expected, and the errors and network calls around the moment it went wrong. A screenshot of a phone shows the symptom and none of those. Below is a template for testers, the reasons mobile reports go missing details, and what the SnagRelay React Native SDK captures so the tester does not have to.
Why mobile reports are harder
On the web, a tester can send a URL and the developer opens the same page. On a phone, there is no URL for the screen. The state depends on the build installed, the OS version, the device, whether the app was backgrounded, the account and the network. A tester describing "the pay button does nothing" is leaving out which build, which screen they came from and what the server said. Testers also cannot open a console on a phone, so the technical context is missing by default.
What the developer needs
- The build. App version and build number, and the channel (TestFlight, internal testing, a debug build). A fix cannot be checked against the wrong build.
- The device and OS. Model and OS version. Bugs are often specific to one platform or one screen size.
- The runtime. The React Native version, whether Hermes is on, and whether the New Architecture is on. These change behaviour.
- The screen and the path to it. Which screen the tester was on, and the last few before it.
- The action and the expectation. What they tapped and what should have happened.
- The requests. What the app sent to the server and what came back, including the failures.
- Errors. JavaScript errors and console output from the tester's build.
- A screenshot with the problem marked.
The general principles are in what developers need in a bug report; mobile adds the first four.
A template for testers
WHAT HAPPENED
[one or two sentences]
EXPECTED
[what should have happened]
STEPS
1. [screen, then tap]
2. [...]
3. [...]
APP
Version / build: [e.g. 1.4.2 (318)]
Installed from: [TestFlight / internal testing / other]
DEVICE
Model and OS: [e.g. iPhone 13, iOS 18.2]
Network: [Wi-Fi / mobile data / flight mode on and off]
Account: [test account used]
HOW OFTEN
[every time / sometimes, and what seems to matter]
A screenshot is attached, with the problem circled.Testers can find the version in the app's settings screen or in TestFlight; make sure your app shows it somewhere, because a missing version number is the most common gap. The steps are the part to push on; how to write steps to reproduce has the rules.
JavaScript errors and native crashes
React Native has two layers, and bugs live in both. A JavaScript error (an undefined value, a failed promise, a wrong response shape) can be reported from the app's code. A native crash, where the app closes, happens below the JavaScript layer and is the job of a crash reporter such as Sentry. They are complementary. Keep the crash reporter for crashes, and use a reporting tool for what testers see and report: wrong totals, missing data, a screen that does nothing.
What the SnagRelay SDK captures
You wrap the app once in SnagRelayProvider, and the tester shakes the phone or taps Report. The report carries:
- An annotated screenshot, where the tester can draw, highlight, comment and redact parts of the image.
- The requests with bodies. The last 50 are captured, successes and failures. A connected agent reads up to 20 of them, failures first.
- Console and JavaScript errors from the tester's build.
- The last 15 screens, if you add the two-line navigation hook. It does not record itself.
- The build: app version, React Native version, Hermes, and whether the New Architecture is on.
Auth headers, tokens and password fields are stripped on the device, and nothing is sent until the tester taps Send. The report goes to the SnagRelay inbox or to Jira, Linear, GitHub, GitLab, Trello or Azure DevOps, and your coding agent can read it over MCP by key. See SnagRelay for React Native for the install steps; it requires React Native 0.76 or newer on the New Architecture, for iOS and Android.
What it does not do
- It does not record a replay of the session or queue reports offline.
- The screen trail needs the navigation hook; without it the report still has the screenshot, the requests and the build.
- In Expo Go, the form, shake and network capture work, but screenshots need a development client or a bare app.
- It is not a crash reporter. Keep Sentry or similar for crashes.
FAQ
What should be in a mobile app bug report?
The app version and build, the device and OS version, the screen and steps, what was expected and what happened, the network state, and a marked-up screenshot. Technical context such as requests and errors helps most.
How can a tester find the app version?
Usually in the app's settings or about screen, or in TestFlight for iOS builds. Show the version and build number in the app, so that testers do not have to look elsewhere.
Can testers report bugs without leaving the app?
Yes, with an in-app reporter. In SnagRelay the tester shakes the device or taps Report, annotates a screenshot and sends it, and the build, requests and errors are attached.
Is this a replacement for Sentry?
No. Sentry is for crashes and exceptions your users never report. SnagRelay is for what testers see and describe, and the context around it.