# Guideline 2.1 - App Completeness: App Crashes During Review

**Guideline:** 2.1 · **Store:** Apple App Store · **Severity:** medium · **Fix difficulty:** medium · **Typical turnaround:** 2-8 hours

Canonical URL: https://appstorereject.com/rejections/apple/2/guideline-21-app-completeness-app-crashes-during-review

## Description

Apple is rejecting your app because it crashed or exhibited a fatal error during their review. This is one of the most frustrating rejection types because the crash may not be reproducible on your own devices. Apple tests on specific hardware and OS versions that may differ from your development environment, and they sometimes have intermittent network conditions or different locale settings. The root cause is almost always one of: (1) a race condition or timing issue that surfaces on slower or different hardware, (2) a nil/null dereference triggered by a code path the reviewer hit that you didn't test, (3) a server-side issue where your API was down or rate-limited during review, or (4) a crash related to the reviewer's specific device, locale, or accessibility settings. Apple's reviewers test on physical devices, not simulators. They also tend to test quickly, which means rapid navigation and state transitions that may expose bugs you've never seen. If they provide a crash log, it's gold — but often the email just says 'the app crashed' without specifics, and you'll need to check your own crash reporting.

## Common variations

- App crashed when we attempted to launch the app
- App crashed during sign-in or authentication
- App crashed when navigating to a specific feature
- App exhibited unexpected behavior and quit unexpectedly
- App froze and became unresponsive during review

## Example rejection email

```
Guideline 2.1 - Performance - App Completeness

We discovered one or more bugs in your app. Specifically, the app crashed when we attempted to navigate to the main content screen after sign-in.

Please see the attached screenshot and crash log for details.

Next Steps:
Please run your app on a device to identify and resolve the issue(s). Note: Testing on a device is required for app approval.

For information about testing your app and preparing it for review, please see Testing a Release Build.
```

## Resolution steps

## Quick Assessment
- **Risk level:** Medium
- **Resolution path:** Fix & Resubmit
- **Typical turnaround:** 2-8 hours to diagnose, plus rebuild/resubmit time

## The Fix

1. **Check your crash reporting** — Look at Crashlytics, Sentry, or whatever crash reporting tool you use for crashes at the time Apple reviewed (check the rejection email timestamp). Filter by the device model and OS version if Apple provided them.

2. **Review Apple's crash log** — If attached, symbolicate the crash log using Xcode. The stack trace will pinpoint the exact line of code.

3. **Test on the specific device/OS** — If Apple mentions a device (e.g., iPhone 15 running iOS 17.4), test on that exact configuration. Borrow a device or use a cloud testing service like BrowserStack.

4. **Check server-side health** — Review your API logs for the review period. If your server was down, rate-limited, or returning errors, that's likely the cause. Add proper error handling for server failures.

5. **Test edge cases** — Sign out/sign in rapidly, toggle airplane mode, switch between tabs quickly, background and foreground the app. Reviewers don't follow happy paths.

6. **Add defensive nil checks** — If you can't reproduce the crash, add guard statements around the area where Apple reported the issue. Crash on force unwraps is the most common single cause.

## Prevention
- Integrate crash reporting (Crashlytics, Sentry) before first submission
- Test on physical devices, not just simulators
- Ensure your backend is stable and has proper error handling during review periods
- Run the app under different locales and accessibility settings
- Use Xcode's Thread Sanitizer and Address Sanitizer during testing

## Appeal guidance

If you believe the crash was caused by a transient server issue that has been resolved, you can explain this in the Resolution Center and request re-review without resubmitting a new binary. Include evidence that the server issue is fixed (e.g., uptime monitoring screenshots). Otherwise, fix and resubmit.

## Before / after examples

**Before:** Force unwrapping an optional user profile that returns nil when the server is slow: `let name = user.profile!.displayName`
**After:** Guard statement with graceful fallback: `guard let profile = user.profile else { showRetryUI(); return }`
**Why it works:** Force unwraps are the number one cause of crashes during review. Apple's test environment may have different network latency than your development setup.

## Common questions

**Can you appeal a 2.1 rejection?**

If you believe the crash was caused by a transient server issue that has been resolved, you can explain this in the Resolution Center and request re-review without resubmitting a new binary. Include evidence that the server issue is fixed (e.g., uptime monitoring screenshots). Otherwise, fix and resubmit.

**How long does this typically take to fix?**

Typical turnaround is 2-8 hours (difficulty: medium). After resubmission, most re-reviews complete within 24-48 hours.

---
*Machine-readable source: https://api.appstorereject.com/api/rejections/detail?slug=guideline-21-app-completeness-app-crashes-during-review*