How to avoid App Store rejection on your first submission

Apple reviewed 9,100,620 app submissions in 2025 and rejected 2,093,244 of them, a little under one in four. The section of the guidelines cited most was not legal or privacy. It was Performance, which covers crashes, broken links, placeholder content, and missing demo accounts: 1,354,418 citations.

So the goal of your first submission is narrow. Give the reviewer an app that works end to end, does what the listing says, and handles personal data in the open. Everything else can ship in version 1.1.

1. Cut anything you're unsure about from version 1

If you're not sure a feature complies with the App Review Guidelines, leave it out of the first build. Get approved first, then add it in an update.

Features worth holding back until you have a live app:

• User-generated content, unless you already have filtering, reporting, and blocking in place (guideline 1.2).
• Links to outside payment for digital goods.
• Anything close to gambling, crypto, health claims, or the Kids category.
• Half-finished screens, "coming soon" buttons, and placeholder text.

Once version 1 is live, a rejected update blocks one feature. A rejected first submission blocks your launch.

2. Put AI consent on its own screen

Since November 2025, guideline 5.1.2(i) names AI directly: "You must clearly disclose where personal data will be shared with third parties, including with third-party AI, and obtain explicit permission before doing so."

If your app sends what users type, say, or upload to a model you don't run, that counts. A line in your privacy policy isn't explicit permission. Build a dedicated screen instead:

• Name the AI provider and say what data you send to it.
• Ask with a clear button. Nothing is accepted by default.
• If a feature can't work without the AI, say so on the screen.
• Link your privacy policy, both in the app and in App Store Connect (guideline 5.1.1(i)).

Developers have been rejected with a consent screen in place because the reviewer never reached it. Tell the reviewer in your App Review notes where the screen appears, and show it in your demo video.

3. Ask Claude where the risk is in your suppliers' terms

Your app carries the rules of every SDK and API inside it. Your App Privacy answers must include the data your analytics, ads, crash reporting, and AI SDKs collect, not only the data your own code collects. Your suppliers also set their own rules: a minimum user age, banned uses, attribution, or data you must not store. If your age rating or your consent screen contradicts one of them, you have a problem with Apple, the supplier, or both.

You don't need to read every policy page yourself. Give Claude the list and ask it where the risk is:

Here are the SDKs and APIs in my iOS app: [list]. Read each one's terms of service, acceptable use policy, and data processing terms. For each, tell me: what data it collects from my users, what it requires me to disclose or enforce (minimum age, consent, attribution, banned uses), and where it conflicts with Apple's App Review Guidelines, my App Privacy answers, or my age rating. Quote each clause with a link. List any page you couldn't read instead of guessing.

Terms change after launch too. To run this every month and get a report of what changed, follow Check your suppliers' terms every month.

4. Leave remote feature flags out of the first build

Apple doesn't ban remote configuration. It does ban two things a flag can drift into. Guideline 2.5.2 bars apps from downloading code that changes features, and guideline 2.5.19 bars "hidden, dormant, or undocumented features." A flag that turns on a screen the reviewer never saw sits close to both lines.

For the first release, ship one fixed experience: the same onboarding, paywall, and features for the reviewer and for every user. With no users yet, an A/B test has no data to read anyway. Add experiments in a later update, once you have traffic.

5. Give the reviewer a way into every screen

Guideline 2.1(a) asks you to "include demo account info (and turn on your back-end service!) if your app includes a login." Before you submit:

1. Create a demo account with real-looking data in it, not an empty state.
2. Confirm your backend is live and your API keys don't expire during review.
3. Open every link in the app and the listing: support URL, marketing URL, privacy policy, and terms.
4. Write App Review notes that say what the app does, where the main features are, where the AI consent screen and paywall appear, and anything that needs a device feature, a location, or a specific region.
5. Record a screen video from first launch to the main feature, and attach it or link it in the notes.

The video matters most when a feature is hard to reach: an account approval step, hardware, or content that only appears after a few days of use.

6. Check your paywall and account rules

Guideline 3.1.2(c) says: "Before asking a customer to subscribe, you should clearly describe what the user will get for the price." On your paywall, show the price, the billing period, what's included, and any trial terms. Add a Restore Purchases button and links to your terms of use and privacy policy.

Three more rules catch first submissions often:

• Sell digital goods and features through in-app purchase (guideline 3.1.1).
• If users can create an account, they must be able to delete it in the app (guideline 5.1.1(v)).
• If you offer a third-party login, also offer an option that meets guideline 4.8, such as Sign in with Apple.

7. Let an agent audit the whole submission

Before you select Submit for Review, connect Claude Code or Codex to App Store Connect through a CLI or an MCP server and have it read everything the reviewer will see. Ask it to check:

• Age rating answers against what users can see, including what an AI chat can generate.
• App Privacy answers against the SDK list from section 3.
• Marketing, support, and privacy policy URLs, and that each one loads.
• Description and screenshots, which must show only features that are in this build.
• App Review notes, demo account, and attachments.
• In-app purchases, which must be attached to this version. Your first in-app purchase goes to review with a new app version.

A prompt to start from:

Read my app's App Store Connect submission for the version in Prepare for Submission. Compare every field with Apple's current App Review Guidelines. List each likely rejection reason with the guideline number, the field it's in, and a fix. Then list what the reviewer can't reach without help, and draft App Review notes that cover it.

Treat the result as a first pass. You still press the button.

If you get rejected anyway

Read the guideline number in the rejection. If the reviewer missed something, such as a consent screen or a login, reply in App Store Connect and point to it before you change any code. If the rejection is right, fix that issue and resubmit. If you think Apple misunderstood your app, you can file one appeal per submission with the App Review Board.

The goal of your first submission isn't to ship every feature you've built. It's to give Apple as few reasons as possible to say no.