LimitedRound 2 is open. Get your first month free, no extra charge.Join the waitlist ›
Fix and resubmit

App Store rejection: app crashes on review (Guideline 2.1)

TL;DR. Guideline 2.1 covers App Completeness, and apps that crash or show obvious bugs during review are rejected. To fix it, reproduce the crash from the attached crash log, test on real devices and current iOS, and clear out placeholder content and broken paths. Apple reviews every resubmission, so the build has to be stable.

What App Store Guideline 2.1 says

Guideline 2.1, App Completeness, asks you to submit a finished app: all features working, accurate metadata, and no obvious bugs or crashes. Apple states that apps which crash, or that show placeholder text, broken links, or incomplete features, will be rejected. Reviewers run the app on real hardware, so anything that fails during their session counts against completeness.

When a crash causes the rejection, the message in Resolution Center usually names the device model and iOS version and, in many cases, attaches a crash log. The official text is on the App Store Review Guidelines page.

Why apps get rejected under 2.1

Crashes during review commonly come from paths you did not test:

  • A fresh install with no existing data, where the app assumes content that is not there yet.
  • Denied permissions, such as the user declining camera, location, or notifications, with no graceful handling.
  • No network or a slow connection, where a request fails and is not handled.
  • A new account or the reviewer's demo account hitting an empty or unexpected state.
  • A newer iOS version or a device model with a different screen size or capabilities.
  • Force-unwrapped optionals, out-of-range indexing, or a backend that returns an error the app does not expect.

The common thread is an unhandled condition. Apple's environment is just a real device in a state your own testing may have skipped.

How to fix it

  1. Read the crash log. Download the crash report from Resolution Center and symbolicate it so the trace maps to your code. The symbolicated frame points to where the crash happened.
  2. Reproduce it. Recreate the reviewer's conditions: the named device or simulator, the same iOS version, a fresh install, denied permissions, and offline mode. Reproducing the crash is the surest path to a real fix.
  3. Fix the cause, not the symptom. Handle the nil value, the empty state, the failed request, or the out-of-range access directly, rather than wrapping the code to swallow the error.
  4. Test the edges. Run a clean install, deny each permission, turn off the network, and try a brand-new account, so the paths reviewers hit are covered.
  5. Verify on TestFlight. Ship the fixed build to TestFlight and confirm it is stable on real devices before you resubmit.

Submitted is not approved. A resubmission goes back through review on real hardware, so the build has to actually be stable, not only stable on your machine.

How AppFlight helps

AppFlight builds native iOS apps in Swift and SwiftUI, runs them in a live iOS simulator as it builds, and includes an automated test gate, so a class of crashes can surface before the build is ever submitted rather than during Apple's review. When Apple returns a 2.1 crash rejection, AppFlight can read the rejection reason and the crash details, work the fix in the generated Swift, for example handling an empty state or a denied permission, and resubmit. AppFlight does not guarantee approval. Some crashes only appear in specific real-device conditions, and Apple reviews every app and every resubmission, so testing on TestFlight before resubmitting still matters.

FAQ

Why does Guideline 2.1 reject crashing apps?

Guideline 2.1, App Completeness, expects a submitted build to be finished and stable. A crash during review means the app is not complete from Apple's view, so it is rejected. The rejection usually includes the device and iOS version, and often a crash log.

My app does not crash for me, so why was it rejected?

Reviewers test on real devices and current iOS, sometimes in conditions you did not, such as a fresh install, denied permissions, no network, or a new account. Crashes often come from those paths. Use the attached crash log and symbolicate it to find the cause.

How do I read the crash log Apple attached?

Download the crash log from the Resolution Center message and symbolicate it so the addresses map to your code. The symbolicated trace points to the function and line where the crash occurred, which is the fastest route to a fix.

Sources

Build this app without opening Xcode.

AppFlight turns a plain-English prompt into a real native iOS app and ships it to the App Store. Round 2 is open: free for your first month.

Join the waitlist