Users report a crash you cannot reproduce. What do you do?
Model answer
1. Get the data. Open the crash reporter (Crashlytics, Sentry or the store consoles). Read the stack trace, and note the app version, OS version, device model and frequency.
2. Find the pattern. Does it happen on one OS version, one device family, low memory, or a specific screen? Breadcrumbs, logs and user actions before the crash help. For JavaScript apps, make sure source maps are uploaded so traces are readable.
3. Form a hypothesis. Typical causes are null or unexpected data from the API, a race during lifecycle changes, out-of-memory kills, or a native library bug.
4. Try to reproduce. Match the device or OS, throttle the network, fill the memory, rotate, background and resume the app.
5. Fix and verify. Ship the fix behind a staged rollout and watch the crash-free rate.
6. Prevent. Add the missing guard, a regression test and extra logging.
Key points
- Start from crash reports: stack trace, version, OS and device
- Look for a pattern across devices, OS versions and screens
- Reproduce under matching constraints such as low memory or slow network
- Use a staged rollout and watch the crash-free rate
Likely follow-ups
- How do you make JavaScript stack traces readable in production?
- What extra logging would you add for the next occurrence?
Common mistakes
- Closing the report as not reproducible
- Testing only on the latest OS and a flagship device