Crash reports and device logs release checklist

Classify crashes by path

Group crashes by onboarding, login, purchase, account deletion, permissions, app launch, paywall, report generation, support, and background tasks. A low-count crash can still block App Review if it happens on the reviewer path.

Record device, OS, build, symbolication status, and last user action where available.

Prioritize release risk

• Launch, login, purchase, restore, and account deletion crashes.
• Crashes on older supported devices or common OS versions.
• Crashes tied to new features, migrations, or SDK updates.
• Crashes that corrupt data or leave paid users locked out.
• Crashes that reviewers can trigger within five minutes.

Use logs as product evidence

Device logs and crash reports should be connected to a reproduction path, not only a stack trace. The release owner needs to know which user promise failed.

AppReviewReady interpretation: crash fixes are conversion work when they protect the path from guide visit to Quick Check to paid report.

Add crash gates to release

1. Symbolicate and classify all recent critical crashes.
2. Reproduce or mark non-reproducible with evidence.
3. Add a regression test or manual release check.
4. Update Review Notes if a fixed path needs special access.
5. Monitor the same crash signature after deployment.

Crash triage record

The record gives support, engineering, and growth a shared severity language.

After launch, compare crash rates with funnel events. A small crash on a high-value path can explain a conversion drop better than traffic data alone.

Do not wait for a statistically large sample before acting on review-path crashes. One reproducible crash during first launch, login, purchase, restore, account deletion, or report creation can be enough to make the app look unfinished to a reviewer and untrustworthy to a buyer.

Pair crash triage with a user-state question: what did the user lose when the app terminated? Losing a draft, payment state, uploaded file, or generated readiness report deserves a different response from a crash after the workflow already completed safely.

Check whether the crash is new to the release candidate or inherited from older builds. A long-standing edge crash may still need a fix, but a new crash introduced by the latest SDK, entitlement, migration, or server contract should have a higher release-stop weight.

Use support language carefully while diagnosing. Tell users what state is safe, how to recover, and whether they should retry, without speculating about Apple review, device blame, or data loss before the evidence is known.

Crash record:
Signature: [name]
Path: [workflow]
Build/device: [details]
Severity: [review/revenue/support]
Fix: [commit or config]
Regression check: [test]
Monitor: [signal]