Guideline 2.1
Guideline 2.1 - App Completeness: App Crashes During Review
Our Take
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.
Resolution Guide
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.
Review Apple's crash log
If attached, symbolicate the crash log using Xcode. The stack trace will pinpoint the exact line of code.
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.
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.
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.
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
Example Rejection Email
Consider Appealing
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
Force unwrapping an optional user profile that returns nil when the server is slow: let name = user.profile!.displayName
Guard statement with graceful fallback: guard let profile = user.profile else { showRetryUI(); return }
What changed: Force unwraps are the number one cause of crashes during review. Apple's test environment may have different network latency than your development setup.
Community Solutions · 0
Sign in to share your solution.
More Guideline 2 (Performance) rejections
- Guideline 2.1 - App Completeness: App Requires External Hardware Not Provided for Review
- Guideline 2.1 - App Completeness: Crashes on Launch
- Guideline 2.1 - App Completeness: Demo Account Not Working
- Guideline 2.1 - App Completeness: IAP Products Not Found in Binary
- Guideline 2.1 - App Completeness: Missing App Icon
- Guideline 2.1 - App Completeness: Missing Launch Screen