Common App Store Rejection Reasons and How to Avoid Them

You submitted your app, and a day later App Store Connect shows a rejection with a guideline number you have never seen before. What went wrong, and how do you avoid it next time? Most App Store rejection reasons turn out to be predictable, and most are fixed without touching much code.

Apple publishes where the trouble usually is. On its App Review page, Apple says that over 40% of unresolved issues relate to Guideline 2.1, App Completeness. Below we go through the guidelines behind the common issues Apple lists, quoting the current App Review Guidelines by number, with what each one means in practice.

The biggest group of App Store rejection reasons: an incomplete submission (2.1)

Guideline 2.1(a) asks for final versions with working URLs and no placeholder text, tested on a device for bugs and stability. It also says, in so many words, to include demo account details if the app has a login, and to turn on your back-end service. Guideline 2.1(b) adds that in-app purchases must be complete, visible to the reviewer and working, or explained in your review notes.

In practice, apps get rejected under 2.1 for things like:

• a demo account that expired, was never given sample data, or needs a one-time code sent to someone's phone
• a staging server that was switched off over the weekend the review happened
• a "Coming soon" screen or a broken link in the settings menu
• a subscription the reviewer could not find because it only appears after a seven-day trial
• a crash on the iPad, because the team only tested on iPhones

The fix is a short routine before every submission: install the exact build on a real device, log in with the demo account from a clean state, tap every menu item, and write review notes a stranger could follow. For example:

Demo customer account: demo@example.com / password in the field above. The account has one past order and one order in progress. To see live tracking, open Orders and tap the order marked Out for delivery. Driver accounts are created by our operations team and cannot be registered in the app.

Metadata that does not match the app (2.3)

Guideline 2.3 says your description, screenshots, previews and privacy information must accurately reflect the app's core experience. These sub-rules deserve particular attention:

• 2.3.1(a): no hidden, dormant or undocumented features. New features must be described with specificity in the Notes for Review; Apple says generic descriptions will be rejected.
• 2.3.3: screenshots should show the app in use, not just title art, a login page or a splash screen.
• 2.3.7: app names are limited to 30 characters, and you should not pack metadata with trademarked terms, popular app names or irrelevant phrases.
• 2.3.10: no names, icons or imagery of other mobile platforms or app marketplaces, which catches screenshots showing an Android phone and "Also on Google Play" badges.

"This could be a website" (4.2) and duplicate apps (4.3)

Guideline 4.2 asks for features, content and UI that lift an app beyond a repackaged website, and 4.2.2 says apps should not be primarily marketing materials, advertisements, web clippings, content aggregators or a collection of links (catalogs are the exception). A web view wrapped around your existing site is the classic 4.2 rejection.

Our honest advice: if your planned app would do nothing your mobile website cannot, do not build the app. A fast, well-built mobile site may serve your customers better and costs far less to maintain. If you do need an app, give it the things an app does well, such as offline access, useful notifications, camera or barcode features, and account features people return to.

Guideline 4.3(a) covers a problem agencies and franchises run into: do not create multiple Bundle IDs of the same app. Ten near-identical apps, one per branch or per city, will struggle. One app where the user picks their branch is the better design anyway. Guideline 4.1 separately rules out copying another app's name, icon or UI.

Privacy, permissions and regulated categories (5.1)

Apple lists privacy policy problems and unclear data access requests among its common issues, and the rules are specific:

• 5.1.1(i): a privacy policy link in App Store Connect and inside the app, explaining what you collect, how you use it, who you share it with and how users can request deletion.
• 5.1.1(v): if your app lets people create an account, it must let them delete it within the app. If the app has no significant account-based features, let people use it without logging in.
• 5.1.1(iii) and (iv): only request data the core features need, use the system picker or share sheet instead of full Photos or Contacts access where possible, and respect a user's refusal. Apple's App Review page also asks for clear purpose strings explaining why each permission is needed.
• 5.1.2(i): get explicit permission through the App Tracking Transparency APIs to track users, and clearly disclose where personal data is shared with third parties, including third-party AI services.
• 5.1.1(ix): apps in highly regulated fields, such as banking, healthcare, gambling, air travel and crypto exchanges, should be submitted by the legal entity that provides the service, not an individual developer.

That last rule matters for healthcare apps in particular. A clinic's booking app published from the developer's personal account is a likely rejection, so plan the clinic's own organization enrollment early.

Payments and sign-in (3.1 and 4.8): a yoga studio app

These two areas trip up apps that sell things. Imagine a yoga studio app that sells passes for in-person classes and a monthly subscription to on-demand videos, and lets people sign in with Google only.

• In-person class passes are services consumed outside the app. Guideline 3.1.3(e) says these must use purchase methods other than in-app purchase, such as Apple Pay or card entry. Selling them through in-app purchase would be wrong.
• The video subscription gives access to digital content inside the app, so Guideline 3.1.1 requires in-app purchase, not license keys or codes. Under 3.1.3(b), people who subscribed on the studio's website can still use it in the app, provided the subscription is also offered as an in-app purchase.
• Google-only sign-in falls under 4.8. An app using a third-party login for the user's main account must also offer an equivalent login option that limits data collection to name and email, lets users keep their email private, and does not collect interactions for advertising without consent. In practice, teams usually add Sign in with Apple here.

One caution on payments: the rules about linking to outside payment options now differ by storefront. The current text exempts the United States storefront from the ban on buttons and external links to other purchasing methods, and some other regions have separate entitlements. Read the current 3.1.1(a) and 3.1.3 text for the countries you sell in before you design the purchase flow.

Two more worth knowing: apps with user-generated content need filtering, reporting, user blocking and published contact details (1.2), and betas or demo versions belong on TestFlight, not the App Store (2.2).

What to do when your app is rejected

1. Read the whole message in App Store Connect, including any screenshots. Note the guideline number and the exact behavior described.
2. If the reviewer misunderstood, reply with specifics: where the feature is, which account to use, what the in-app purchase provides.
3. If they are right, fix it, check the rest of the app for the same problem, and resubmit with notes that say what changed. Apple says 90% of submissions are reviewed in less than 24 hours on average, so a clean resubmission usually costs days, not weeks.
4. If you believe the app complies, you can appeal to the App Review Board with specific reasons. Apple allows one appeal per rejected submission, so make it count.
5. If a live app has a critical bug, request an expedited review and include steps to reproduce it.

What not to do: hide a feature from the reviewer and switch it on after approval. That is exactly what 2.3.1(a) prohibits, and 2.3.1(b) says egregious or repeated behavior is grounds for removal from the Apple Developer Program. The risk is your whole account, not one version.

Most App Store rejection reasons are cheaper to prevent than to fix. Before your next submission, run through our app launch checklist, and give someone who did not build the app a real device, the demo account and your review notes. If they get stuck, a reviewer will too. Our QA team does this kind of pre-submission pass, and if you have a rejection in hand right now, our iOS developers can read it with you and work out what needs to change. You can also send us the rejection message directly.