A genuine crash during App Review normally requires a code fix and a new build. Start with Apple’s device details and crash evidence, then reproduce the exact submitted archive on real hardware from a clean state.
The short version
- A genuine crash during App Review normally requires a code fix and a new build.
- Debug the reviewed artifact, not your latest local branch. A mismatch between those two can waste an entire cycle.
- Download every attached crash log and note the device and OS.
- Do not promise approval; give App Review a testable path.
Identify the crashing artifact and path
Start with identity, not speculation: version, build, archive, dSYM, device, OS, and the action immediately before termination. Debugging a newer branch can hide the defect Apple actually ran.
Download Apple’s crash attachment when provided and preserve it beside the matching archive. Record whether the process terminated on launch, after a user action, during background return, or after a service response; those are different search areas.
Build a crash reproduction matrix
Run the release artifact on physical hardware from a fresh install. Vary only one condition at a time: OS, device family, account state, connectivity, permission choice, or remote payload. This produces a useful matrix instead of an anecdotal “works here”.
- Download every attached crash log and note the device and OS.
- Symbolicate the report against the submitted archive and dSYM.
- Install the exact build through TestFlight on physical hardware.
- Test clean data, empty state, weak network, and oldest supported OS.
- Fix the traced failure, increment the build, and rerun the matrix.
Crash evidence should connect a symbolicated frame or reproducible trigger to the submitted build. Keep the regression test, release run, and exact reviewer path; do not bury the reply in an internal stack trace.
Decide when the crash requires another binary
A reproduced crash requires code and another build. A supplied but unsymbolicated report requires investigation first. With neither a reproduction nor usable evidence, request the precise log and steps before making random changes.
| Situation | Next action | New build? |
|---|---|---|
| Reproduced crash | Fix traced code and submit a new build | Yes |
| No crash, log supplied | Symbolicate and investigate before resubmitting | Not yet |
| No crash and no useful evidence | Ask Apple for the log and exact steps | No initial rebuild |
| Remote error causes a crash | Add safe failure handling | Yes |
Let the crash evidence choose the route: do not replace a binary for an uninvestigated report, and do not reuse one after changing executable failure handling.
Start with the reviewed artifact
Record the version and build number from App Store Connect. Keep the archive and dSYM that produced it. Your current branch may contain changes that never reached Apple, so a successful local run proves little.
Match any crash report to the correct symbols. Unsymbolicated addresses are clues, not a reliable file-and-line diagnosis.
Reproduce on real hardware
Use a physical device and the closest available OS and form factor. Include an iPad compatibility run when relevant. Test a release configuration through TestFlight rather than relying only on a simulator or debug build.
Begin with a fresh install. Remove saved credentials, seeded objects, and cached configuration.
Exercise failure states
Switch off the network during launch. Return malformed or empty API data in a controlled test environment. Test an expired session, denied permission, zero records, low memory, and a cold start after termination.
Look for forced unwraps, forced casts, array indexing, missing resources, migration errors, and unhandled asynchronous failures.
Fix and prove the same path
Change the smallest code path that explains the crash. Add a regression test where practical, create a release archive, and rerun the exact steps on hardware.
Your reply should name the cause at a useful level, the new build number, the tested device and OS, and the path Apple can repeat. Do not paste internal stack traces or claim universal stability.
If the reviewer note crosses failure classes, use the App Store rejection map to separate the app crashes during review symptom from unrelated issues.
Read the crash evidence before editing code
A crash report is valuable only when it matches the submitted archive. Confirm the executable UUID and use the corresponding dSYM before treating an address as a source location. Start from the crashed thread and exception context, then compare it with the reviewer’s action and your release logs.
No attachment does not justify a blind rebuild. Ask for the crash log, device, OS, and exact path. Meanwhile, test the most likely release-only boundaries: missing production configuration, data migration, resource lookup, signing-dependent services, and responses that differ from development.
Cover cold launch and resumed launch separately
A clean launch tests migrations, first-run configuration, permissions, and empty credentials. A resumed launch tests stale sessions, background task completion, scene restoration, and state created by an earlier version. Reinstall, upgrade from the prior public version when relevant, terminate, relaunch, background, and return.
For each run, record build, device, OS, account, network condition, trigger, and result. One successful run on your primary phone does not close a crash that depends on an older supported OS or an iPad layout path.
Regression-proof the traced boundary
Replace unsafe assumptions with explicit handling and add a test at the smallest reproducible boundary. If malformed JSON caused an index failure, test empty and partial payloads. If an expired session caused a forced unwrap, test the unauthenticated transition. Then archive a release build and repeat Apple’s route on hardware.
In your reply, identify the corrected path without exposing implementation secrets, name the new build, and provide concise verification steps. Use the 2.1 family guide if the message also includes access or incomplete-content symptoms.
Before replacing the build, symbolicate the reviewer’s crash log with the matching archive and dSYM, then save the exception type and first relevant frame in your evidence record. A log from another archive can point at the wrong code. Reproduce the corrected path twice from a clean install and once after backgrounding the app so the verification covers both launch states Apple may have exercised.
Verify against Apple before resubmitting
Rules and App Store Connect interfaces can change. Reopen the Apple pages that support this decision before you act: App Review Guidelines, 2.1 App Completeness, Reply to App Review messages. These are the primary policy and workflow sources used for this guide, opened on 4 August 2026. Recheck the current 2.1 language before describing a crash as an App Completeness correction.
FAQ about app rejected crashing on launch
Does a crash rejection need a new build?
Usually yes. A genuine runtime crash is binary behavior and cannot be repaired through metadata.
What if the app works in the simulator?
Test the release build on physical hardware. Simulator success does not reproduce every device, memory, signing, or production-service condition.
Should I resubmit when I cannot reproduce?
Ask for the full crash report and precise steps first. Resubmit only when you have a reasoned fix or evidence for a retest.
Can a backend outage cause a crash rejection?
Yes, if the app does not handle the failed request safely. Restore the backend and repair the failure path.
Conclusion
Match evidence to the reviewed archive, reproduce the trigger on hardware, regression-test the boundary, and submit the tested replacement build only when the crash is explained.
Sources and references
- App Review Guidelines, 2.1 App Completeness (accessed 2026-08-04)
- Reply to App Review messages (accessed 2026-08-04)