The short answer
According to Apple, on average over 40% of unresolved issues come from guideline 2.1, App Completeness: crashes, placeholder content and information the reviewer needed but did not get. Most of the rest come from a handful of guidelines on metadata, minimum functionality, spam, privacy and payments. Nearly all of them can be caught before you press Submit.
Apple says it typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. A rejection usually costs days rather than weeks, but on a launch date, days are what you do not have.
The common rejections, by guideline
| Guideline | What it covers | A typical trigger |
|---|---|---|
| 2.1 App Completeness | Crashes, bugs, placeholders, review information | A crash on launch, a dead link, no demo account |
| 2.3 Accurate Metadata | Description, screenshots, previews | Screenshots of a splash screen, or of features the app does not have |
| 4.2 Minimum Functionality | Apps that are not app-like | A website wrapped in a web view |
| 4.3 Spam | Duplicates and crowded categories | Many near-identical apps, or one more of a saturated kind |
| 5.1 Privacy | Privacy policy, permissions, accounts | No way to delete an account inside the app |
| 3.1 Payments | In-app purchase and subscriptions | Digital features unlocked with a code instead of in-app purchase |
| 4.8 Login Services | Third-party sign-in | Only Google or Facebook sign-in, with no private alternative |
2.1 App Completeness: crashes, placeholders and missing information
Apple asks for final versions: tested on a device, with working links, no placeholder text, and everything a reviewer needs to reach every feature. It rejects builds that crash or show obvious technical problems. The usual causes are dull, which is good news, because dull problems are easy to check for:
- Test on a device running the latest iOS, not only in the simulator, and fix every crash you can reproduce.
- Remove placeholder text and images. Lorem ipsum, test products and empty screens count as unfinished.
- Check every link, including your support URL and privacy policy. Apple requires both, and both must work.
- Give the reviewer a demo account in the App Review Information section of App Store Connect, and keep your backend switched on during review.
- Make in-app purchases reviewable. They must be complete, visible to the reviewer and working. If one cannot be found in the app, explain why in the review notes.
- Explain anything unusual. Special settings, hardware or a hard-to-reach feature belong in the review notes, with a demo video if needed.
2.3 Accurate Metadata: screenshots, names and descriptions
Your listing has to describe the app people will actually get. The points that catch apps most often:
- Screenshots must show the app in use (2.3.3), not only title art, a login page or a splash screen. Text overlays are fine as long as they explain the app rather than hide it.
- Say what costs extra (2.3.2). If featured items or levels need an in-app purchase, the description and screenshots must make that clear.
- Names are limited to 30 characters (2.3.7), and keywords must describe the app. Trademarks, competitors’ names and prices do not belong in your metadata.
- Keep it about Apple platforms (2.3.10). Names, icons or imagery of other mobile platforms are not allowed in the app or its metadata.
- Describe significant changes in What’s New (2.3.12). Generic notes are fine for bug fixes, not for new features.
Getting screenshots to the right sizes is a separate job: see our App Store screenshot sizes reference and checker.
4.2 Minimum Functionality: an app, not a website
Apple wants features, content and interface that “elevate it beyond a repackaged website”. A web view around your site, a collection of links or marketing material dressed up as an app will usually not pass. The fix is to give people a reason to install: offline access, notifications they asked for, the camera, widgets, or simply an interface that works the way iPhone apps do. This is a large part of why we only build natively in Swift.
4.3 Spam: duplicates and crowded categories
Guideline 4.3 has two halves. 4.3(a): do not submit several bundle IDs of the same app, such as one app per city. Ship one app and offer the variations inside it. 4.3(b): do not submit apps that are indistinguishable from what is already widely available. Apple names dating, flashlight, sound effect, wallpaper, simple timer and fortune telling apps as categories it will only accept with a meaningfully different or improved experience.
Apps built from a commercial template or an app generator have their own rule, 4.2.6: they are rejected unless the provider of the app’s content submits them.
5.1 Privacy: the policy, permissions and account deletion
- A privacy policy, linked twice: in the App Store Connect metadata and inside the app. It must say what data you collect, how and why, confirm that third parties protect it equally, and explain retention, deletion and how to withdraw consent.
- Clear purpose strings. Every permission prompt needs an Info.plist text that says plainly why the app needs access. Vague purpose strings are a common rejection.
- Ask for less. Request only data the core feature needs, and prefer the system photo picker or a share sheet to full access to Photos or Contacts.
- Account deletion. If people can create an account in your app, they must be able to delete it in the app too. And if the app has no real account-based features, let people use it without signing in.
- Third-party AI. Apple asks you to disclose clearly when personal data is shared with third parties, including third-party AI, and to get explicit permission first (5.1.2).
3.1 Payments: in-app purchase and subscriptions
- Digital features need in-app purchase (3.1.1). License keys, QR codes and similar mechanisms cannot unlock content or functionality.
- Credits do not expire. Credits or currencies bought through in-app purchase may not expire, and restorable purchases need a restore option.
- Subscriptions must give ongoing value (3.1.2), last at least seven days and work across all of the person’s devices.
- Say what people get before they subscribe (3.1.2(c)): how much, how often, and what access.
Rules on linking out to other ways to pay differ by storefront, and the United States storefront is now treated differently from the rest. Check 3.1.1(a) and 3.1.3 for each market you sell in.
4.8 Login Services: when you need a second sign-in option
If a third-party or social login, such as Google or Facebook, sets up the person’s main account, you must also offer an equivalent login service that limits data collection to name and email, lets people keep their email address private, and does not collect their activity for advertising without consent. Sign in with Apple is the usual way to meet this. Apps that only use your own company’s accounts, and some education, enterprise and government ID apps, are exempt.
Extra rules for AI apps
Guideline 1.2 names AI content creation apps alongside social and user-generated content apps. They need a way to filter objectionable material, a way to report content with timely responses, the ability to block abusive users, and published contact details. Add the third-party AI disclosure from 5.1.2 and you have the two rules that catch AI apps most. When we build an AI app, both are planned from day one; see AI app development.
What to do after a rejection
- Read the message in App Store Connect. The App Review section names the guideline the submission did not follow. Fix exactly that first.
- Reply if something was misunderstood. You can correspond with App Review before you resubmit. A short, specific explanation often settles it.
- Appeal only with reasons. If you believe the app complies, you can appeal to the App Review Board: one appeal per rejected submission, with specific reasons, after answering any requests for information.
- Ask about bug fix submissions. If a bug fix update is held up by an unrelated issue, Apple may let you fix that issue in the next submission, as long as there are no legal or safety concerns.
- Request an expedited review for a critical bug fix or an event-related launch, and include the steps to reproduce the bug or the event date.
- Book a call. Apple offers 30-minute video appointments with App Review to talk through guidelines and common rejections.
A checklist before you submit
- Tested on a real device with the latest iOS, with no crashes
- No placeholder text, images or test products
- Support URL and privacy policy live, linked and working
- Demo account and review notes filled in, backend running
- In-app purchases submitted, visible and working, with restore
- Screenshots that show the app in use, at the required sizes
- Every permission prompt with a clear purpose string
- Account deletion inside the app, if accounts can be created
- Equivalent private login, if you offer social sign-in
- Reporting and blocking, if people or AI create content
Sources: Apple’s App Review Guidelines and App Review pages.
Related: App Review Guidelines changes · App Store screenshot sizes · App Store Optimization · iOS app development