App Store Review Checklist

Apple rejects a huge share of apps on the first submission. Almost always for the same handful of reasons.

Some are obvious: a crash on an old iPhone, or a purchase that will not load. The ones that surprise people are not bugs. They are a missing checkbox, a link in the wrong place, or one word in a subscription name. Boring things you would never think to test. Any one of them can cost you two weeks.

I went through the guidelines, rejection stories, and rules I could find, and turned them into one list. Here is the whole thing, in plain English.

First, think like the reviewer

They are not judging whether your app is clever, or how long you spent on it. They have a long queue and a few minutes per app. They test on an old iPhone, on a slow connection, with a half-dead battery. They are looking for one clear reason to reject you and move on.

Your job is to find that reason first, on your own old phone, before they do.

The five things that sink most apps

Crashes. Subscriptions that are not crystal clear. Missing legal links. Privacy answers that do not match what the app really does. An app that feels like a website in a box.

Fix all five before you submit. Then deal with the sneaky metadata traps most people never see.

Crashes, and anything that looks half-finished

One crash on an old device and you are done. That is Guideline 2.1, and it is not only about crashes.

A button that does nothing counts too. So does a spinner that never stops, a half-built screen, a greyed-out feature, or leftover placeholder text. Reviewers treat every screen as final.

• Test every flow on a real release build, on a cheap physical phone — not only in debug on your Mac.
• Compile with the current required Xcode and SDK.
• Answer the export-compliance question. Set ITSAppUsesNonExemptEncryption in Info.plist (usually false if you only use normal HTTPS) so the build does not sit in “Missing Compliance.”

The purchase

Two things quietly fail people here. The purchase does not load in the sandbox on first launch. Or Restore is buried under a long scroll.

• Put Restore somewhere obvious — on the paywall or in Settings.
• Run the full loop the way a reviewer will: buy the subscription, delete the app, reinstall it, tap Restore, and check that access comes back.
• If that loop breaks, Guideline 3.1.1 can bounce you. A missing Restore is one of the most common ways it happens. Test it twice.

Say the price in plain words

Be direct. For example: seven-day free trial, then $4.99 a month, cancel anytime. Match every number to App Store Connect. Put the Terms link on the paywall itself, not at the bottom of a long page.

Fill out the App Privacy label honestly

This is the privacy “nutrition label” on your App Store page. In App Store Connect it lives under your app → App Privacy → Get Started. It is a questionnaire, not a free-text box.

You tick every type of data the app collects (contact info, identifiers, usage data, location, and so on). Then you say if it is linked to the user, if it is used to track them across other apps, and what it is for.

Your SDKs collect more than you think. Analytics, ads, and crash tools all grab data, and Apple holds you responsible. Fill this in last, after you check your own code and every third-party SDK. Declare less than they collect and you can get flagged on the first pass.

Accounts and permission prompts

• Write a real sentence for every permission prompt — why you need it — not “for functionality.”
• If the app has accounts, users must be able to delete the account inside the app (Guideline 5.1.1(v)). A web-only delete link is not enough.
• If a feature works without an account, do not force sign-up (Guideline 5.1.1(i)).

Make it feel like an iPhone app

An app that fights the platform looks foreign. Use normal navigation, tap targets of 44pt or bigger, and a real dark mode. Apple’s Human Interface Guidelines explain how iOS apps should look. That is guidance, not a line-by-line test. Reviewers rarely reject for style alone.

What does get bounced is a UI that is broken or confusing. Hunt for the small stuff: a janky cold start, a launch icon that does not match the store icon, an iPad layout that overlaps when someone rotates the device. It should feel at home on iOS, not like a website wearing an app costume.

Legal links and subscriptions reviewers actually check

Privacy, EULA, and Terms of Use are three different things

Apple uses three names that feel like one thing: License Agreement, EULA, and Terms of Use. Here is the clean version.

Your privacy policy is separate. You need your own privacy-policy URL under App Privacy → Privacy Policy in App Store Connect. Link it inside the app too, usually in Settings. Every app needs this.

The EULA (License Agreement) is the license people use the app under. In App Store Connect it lives under App Information → License Agreement. You have two choices.

• Apple’s standard EULA. The default. You write nothing. Most indie apps, including most subscription apps, are fine here. One quirk: with the standard EULA, Apple does not show a license link on your product page.
• A custom EULA. Only if you have your own legal text. Paste it under License Agreement → Edit → Custom, then pick the countries. Anywhere you skip falls back to Apple’s standard.

The Terms of Use link is the one that gets subscription apps rejected. Because the standard EULA link never shows on your product page, a reviewer cannot find your terms. Guideline 3.1.2 wants a working Terms of Use link in the app and in your App Store metadata.

The easy fix: even with the standard EULA, add a Terms of Use link in two places — near the bottom of your App Store description, and on the paywall next to Privacy Policy and Restore. You can use Apple’s standard EULA URL: https://www.apple.com/legal/internet-services/itunes/dev/stdeula/

For a normal subscription app: custom EULA is optional. Terms of Use link is required on the paywall and in your description. Privacy Policy link is required on the paywall and in App Store Connect. The rejection is almost never “you did not write a custom EULA.” It is “the reviewer could not find Terms of Use.” Miss the links and you can get 3.1.2 or 5.1.1.

Subscriptions: spell out the whole deal

Two places have to agree, and reviewers check the real screen, not only the metadata.

On the paywall, before the tap, show all of this:

• The plan name
• The length
• Exactly what they get for that period
• The exact price
• The auto-renew line in plain words: billed to their Apple ID at confirmation, renews at the same price unless they cancel at least 24 hours before the period ends, and they can manage or cancel in Settings.

In App Store Connect, put those same numbers in your App Store description. A vague paywall is one of the most common 3.1.2 rejections.

The trap nobody sees: the plan name

Your subscription can be perfect and still get rejected — on its name.

The in-app purchase display name and description are reviewed on their own. They have to describe the product, not sell it. No “50% OFF.” No “Best Value.” No “Limited Time.” No prices in the name. That is a 2.3.2 metadata rejection. The app can be fine. The name is not.

This applies in every language you sell. Each localization needs the clean name and the full disclosures (auto-renew, price, Terms and Privacy links). Each plan also needs its own review screenshot in App Store Connect, or you cannot submit it.

Quiet metadata rejections

The app can pass. The store page can still fail.

• Screenshots must show the real app in use, not marketing frames with slogans (2.3.3).
• If you support iPad, upload iPad screenshots too, or it will not submit.
• Your Support URL must be a real working page. A 404 or parked domain bounces you (1.5).
• App name, subtitle, and keywords cannot include competitor names, trademarks, prices, or “free” (2.3.7).
• If you offer Google or Facebook login, you also need an equal privacy-preserving option such as Sign in with Apple (4.8).
• If you touch the ad identifier, show the App Tracking Transparency prompt first (5.1.2(i)).

Does your app earn its spot?

One of Apple’s most-cited rejections is basically “we have seen this before.”

A web page wrapped in an app icon, or a brochure that could just be a website, gets bounced under Guideline 4.2, Minimum Functionality. Give people things Safari cannot: notifications, offline use, real device features, real interaction.

If the app looks like fifty others in its category, Guideline 4.3 (Spam) can reject it outright. Ship one real app, not thin copies, and lead screenshots with what is actually different.

If people can post, Apple wants four things

If people can post comments, profiles, chat, photos, or even what an AI chatbot writes back, that is user-generated content. Guideline 1.2 applies. Apple wants proof you can keep it from turning ugly. You need all four:

1. A content filter — some way to catch bad material, not only clean up after a complaint.
2. A report button — any user can flag content, and you act on reports.
3. A block feature — a user can block someone who is harassing them.
4. A way to reach you — published contact info, not a dead end.

Users also have to accept terms that say you do not tolerate abuse. That is your EULA doing real work. Miss any of this and you can be rejected. This used to be a social-app rule. It now hits AI chatbot and AI-wrapper apps too, because what the model generates lives in your app.

New in 2025 and 2026

• Age ratings changed in 2025. 12+ and 17+ are gone, replaced by 13+, 16+, and 18+ (4+ and 9+ stay). The new questionnaire became required on January 31, 2026. Until you fill it in honestly, App Store Connect will not let you submit updates.
• Third-party AI is now regulated. If the app shares personal data with a third-party AI service, you have to disclose it and get clear consent first (5.1.2(i), in force since November 2025).

Film it. Hand them the map.

Reviewers reject what they cannot find.

Record a 90-second screen capture with no cuts. Start the moment you tap the app icon. Walk through onboarding, sign-up, setup, every main feature, then the exact taps to reach the paywall, buy, and restore. Attach it in App Review Information → Attachment.

If there is a login, add a demo account with two-factor off. Reviewers cannot receive your codes. A reviewer who can watch the whole flow has less to hunt for — and less to fail you on. This one step kills more rejections than almost anything else.

If you do get rejected

Find the real reason

The email is only a summary. The detail lives in App Store Connect → your app → Resolution Center. You will see the exact guideline number, a short “Next Steps” note, and sometimes a screenshot of the failed screen. That guideline number is your map back to approval.

Note whether it is a metadata rejection (fix in App Store Connect, no new build) or a binary one (needs a new build). That changes how fast you can get back in.

Reproduce it their way

Old device. Slow network. Fresh install. No saved login, no old purchase. A lot of “cannot find the purchase” and “it crashed” reports vanish the moment you stop testing in debug on your own phone.

Fix that one thing. Do not rebuild the app.

Make the change the guideline points to. The urge to rewrite everything is real. A calm build with one small fix clears review faster than a three-day panic rewrite that hands the next reviewer three new things to question. Change the one thing. Ship it. Wait.

If you reply, keep it short and kind

The reviewer can clear you in one message. Be polite. Point to the exact screen. Attach a screenshot. Say what you changed and how you tested it. Do not argue. If you truly disagree, there is a formal appeal through the App Review Board — a separate form, not the Resolution Center reply. Bring proof, not feelings.

You can copy these replies

If you fixed it: “Hi, thanks for the review. We fixed the issue under 3.1.1. Restore Purchases now sits on the paywall without scrolling (screenshot attached), and we re-tested it in the sandbox. The fix is in build 1.0.2, just submitted. Happy to send anything else you need.”

If they missed it: “Hi, thanks for reviewing. The purchase may have been hard to find. To reach it: open the app, tap Profile, then Go Premium. I have attached a short recording of the full flow.” Never say “you are wrong.” Say “here is how to see it.”

If it is vague, just ask: “Could you share the device, the iOS version, and the steps where you hit this? A screenshot would help us fix it fast.” That is a normal ask. Reviewers often answer in the same thread.

What it comes down to

You do not need luck to pass review. You need to remove every reason to fail before you hit submit.

A checklist is a quiet promise that you will not get lazy at the finish line and trust something that “probably works” when you never opened it on a cheap phone. That is the difference between shipping in one calm day and bouncing with a reviewer for two hard weeks.

Boring beats clever here. Every time.