A crash spike the morning after a release is a ranking problem before it is a debugging problem. Use App Quality Insights with Gemini analysis, Crashlytics segmentation and Xcode Organizer to turn raw crash and ANR feeds into ranked, evidence-backed hypotheses — then prove the fix through a staged rollout, not a hopeful full release.
Tier: Core · Workflow area: Mobile engineering & release
This playbook is the triage loop: pull symbolicated evidence into the IDE, let AI explain and rank, verify the hypothesis against segmentation data, and close the loop with rollout metrics.
Skip AI analysis for crashes with a one-frame obvious cause in your own code — just fix them.
Rank before you read. Sort clusters by users affected × trend, not raw event count. One device model looping a crash inflates counts; 2% of all users hitting it once is worse. In App Quality Insights, filter to the spiking release and sort by impacted users; do the same in Crashlytics/Organizer for iOS.
Run AI analysis on the top clusters with full evidence. In Android Studio, select the crash and use the Gemini insights action — it reads the stack, and with code context enabled can point at your actual source. Push it past the summary:
For this crash: 1) most likely root cause in OUR code (cite file and
line), 2) alternative explanations and what evidence would separate
them, 3) why it may have started in 4.12.0 - here is the changelog
for the affected area, 4) a minimal reproduction scenario.
For iOS or out-of-IDE work, paste the fully symbolicated stack, the release diff for the involved files, and breadcrumbs into your assistant with the same four-part prompt.
Interrogate ANRs by thread, not vibe. ANR reports carry all thread stacks. Ask specifically:
Here is the ANR report. Identify what the main thread was blocked on,
which thread (if any) holds the resource, and classify: main-thread
I/O, lock contention, binder call, deadlock, or slow broadcast.
Quote the exact frames supporting the classification.
The quote requirement is the anti-hallucination gate — a claimed deadlock must show both stacks.
Verify the hypothesis with segmentation before writing the fix. Every hypothesis predicts a distribution. A NullPointerException from a race predicts spread across devices; a vendor-specific frame predicts one OEM; a memory crash predicts low-RAM devices and background state. Check the prediction in Crashlytics/vitals dimensions (device, OS, orientation, foreground/background, OS + app version pair). A hypothesis whose predicted segmentation fails is wrong regardless of how convincing the explanation read.
Fix, then prove it through a staged rollout. Ship the fix at 10% (Play staged rollout / phased release on the App Store), compare the cluster's crash-free-users delta between cohorts, and only then expand. Annotate the crash cluster (notes/links) with the verdict so the next engineer inherits conclusions, not archaeology. If the cluster does not drop in the 10% cohort, halt the rollout — you fixed a co-traveler, not the cause.
AI reads stacks faster than you; segmentation data decides truth. The loop is rank → AI hypothesis with citations → segmentation check → staged-rollout proof — and no fix is "done" until the cohort numbers say so.
runBlocking off a coroutine still blocks; re-check the classification after the fix.Crash stacks frequently embed user-adjacent data (file paths, URLs, account states in breadcrumbs). Where policy restricts external AI: use the in-tenancy option (Gemini via your org's agreement, or a Bedrock/Azure-hosted model) with the same prompts; otherwise sanitize stacks — strip breadcrumb values, keep frames and thread states — before pasting. The segmentation and staged-rollout steps are dashboard work and unaffected.
Breadcrumbs and custom keys are the highest-leak-risk part of a crash report. Review what your app logs into them before any report leaves your tooling — ideally before you ever need this playbook.