App Store rejection reasons: the complete list with fixes
The full ruleset lives on Apple's App Store Review Guidelines page. This list summarizes the common rejections and points to detailed fixes.
App completeness and performance (Guideline 2)
This is the largest single bucket. Apple expects a finished, stable app, with working access for the reviewer.
- Guideline 2.1, App Completeness. Crashes, bugs, placeholder content, broken links, or a login the reviewer cannot pass. The most common subtype is the missing demo account, where the reviewer cannot sign in to see the app. See Guideline 2.1 app completeness and the demo account rejection fix.
- Guideline 2.3, Accurate Metadata. Screenshots, description, or preview that do not match what the app actually does. See Guideline 2.3 accurate metadata.
Design and functionality (Guideline 4)
Apple judges whether the app belongs on the store and is genuinely app-like.
- Guideline 4.2, Minimum Functionality. The app is not useful, unique, or app-like enough, often because it is a thin webview of a website. See Guideline 4.2 minimum functionality and app rejected for looking like a website.
- Guideline 4.3, Spam. Duplicate apps across many Bundle IDs, or an app indistinguishable from what already exists. See Guideline 4.3 spam fix.
- Guideline 4.8, Login Services. The app offers a third-party or social login but no equivalent privacy-focused option like Sign in with Apple. See Sign in with Apple rejection, Guideline 4.8.
Privacy and data (Guideline 5.1)
Privacy rejections are common and often involve a mismatch between what the app does and what it discloses.
- Guideline 5.1.1(i), Data Collection and Storage. Missing or inaccurate privacy policy, or undisclosed third-party SDK data collection. See Guideline 5.1.1(i) missing privacy policy and the broader Guideline 5.1.1 data collection and storage.
- Guideline 5.1.1(v), Account Deletion. The app supports account creation but does not let users delete their account in-app. See missing account deletion, 5.1.1(v).
- Guideline 5.1.2(i), Data Use and Sharing. Personal data is shared with a third party, including third-party AI, without clear disclosure and explicit consent. See Guideline 5.1.2(i) third-party AI consent.
Upload and privacy manifest errors (ITMS codes)
Some failures happen at upload, before human review, and come back as an ITMS error code rather than a guideline number.
- ITMS-91053, Missing API declaration. The app or an SDK uses a required reason API without declaring it in a privacy manifest. See ITMS-91053 missing API declaration fix.
How to use this list
- Find the guideline number or ITMS code in your App Review message.
- Open the matching section above and its fix page.
- Make the substantive change the fix page describes, not a cosmetic one.
- Add clear App Review notes explaining what you changed, then resubmit.
Apple reviews every resubmission, and a resubmission can be rejected for a different reason than the first. Treat each guideline as a real requirement rather than a box to tick.
How AppFlight helps
AppFlight builds native iOS apps in Swift and SwiftUI from a plain-English prompt and runs the full path to the App Store, including code signing, TestFlight, and submission. When Apple returns a rejection, AppFlight reads the rejection reason, works on the specific issue, and resubmits the build, whether that is a demo account, a privacy policy, an account deletion flow, a Sign in with Apple option, or a privacy manifest declaration. AppFlight does not guarantee approval. Apple reviews every app and every resubmission, and some rejections, such as a 4.3 clone or a 4.2 product that only makes sense as a website, are not solved by rebuilding. The honest fixes are the ones on the pages above.
FAQ
What are the most common App Store rejection reasons?
The most common are Guideline 2.1 app completeness, including crashes and missing demo accounts; Guideline 4.2 minimum functionality; Guideline 4.3 spam and duplicates; the 5.1.1 privacy rules, including privacy policy and account deletion; and metadata issues under 2.3. Each has a specific fix.
How do I find which guideline my app was rejected under?
Open the message from App Review in App Store Connect. It cites a guideline number, such as 2.1 or 5.1.1(v), or an upload error code such as ITMS-91053. Match that number to the matching section below, then follow its fix page.
Does fixing the rejection guarantee my app gets approved?
No. Apple reviews every app and every resubmission. Fixing the cited issue addresses the reason you were rejected, but the reviewer evaluates the whole app again, and a resubmission can be rejected for a different reason. Submitted is not approved.