Crash and error monitoring in an app
What to install on day one
A crash-reporting tool with symbol mapping so reports are readable, and a basic event mechanism that lets you reconstruct the path leading to a crash. Both exist as a service and aren't a project.
What to measure
The share of crash-free launches is the primary metric; aim for a level where a crash is an exceptional event and not background noise. Beside it: prolonged freezes, network errors by path, and events the user abandoned midway.
Break down by version and by model. It almost always turns out the problem is concentrated in one place.
What to do with a report
Set a rule: a crash touching more than one percent of users goes into work immediately. And keep a version and build number on every report — without them, half the investigation is guesswork.
Going deeper
Add breadcrumb logging at the key points of long processes: sync start, finish, failure, retry. A large share of complaints aren't crashes but processes that got stuck, and those are invisible to crash tools.