Guideline 2.1

Guideline 2.1 - App Completeness: App Crashes During Review

Medium SeverityMedium FixTypical Fix: 2-8 hours1 Report
Also known as:App crashed when we attempted to launch the appApp crashed during sign-in or authenticationApp crashed when navigating to a specific featureApp exhibited unexpected behavior and quit unexpectedlyApp froze and became unresponsive 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

01

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.

02

Review Apple's crash log

If attached, symbolicate the crash log using Xcode. The stack trace will pinpoint the exact line of code.

03

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.

04

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.

05

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.

06

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
  • Example Rejection Email

    From:Apple App Review Team
    Subject:Guideline 2.1 - App Completeness: App Crashes During Rev
    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.

    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.

    Generate Appeal

    Before & After

    Before — Rejected

    Force unwrapping an optional user profile that returns nil when the server is slow: let name = user.profile!.displayName

    After — Approved

    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

    View all Guideline 2 rejections