Getting your app approved on the App Store.
What they check, and why.

A person, a checklist, and about ten minutes.

App Review is a human with your build on a phone and an iPad, your screenshots, your description, and a set of published guidelines. They are not judging whether the app is a good business. They are checking whether it does what it says, whether it is safe for the person holding the phone, and whether Apple's own rules about money, accounts, and platform are respected. Most rejections happen because a builder never looked at the app the way a reviewer does.

The rules that get apps sent back fastest.

1. Payments inside the app.

   If a person buys something digital that they use inside the app (a subscription, a feature, credits, content), Apple expects its in-app purchase system, not a card form or a Stripe checkout inside the app. Physical goods and services used outside the app are different. Why: Apple treats digital purchases on its platform as its commerce, and the review is strict about it. Knowing which side of that line your product sits on is the single most important question before you build a checkout.

2. Sign in with Apple.

   If your app offers a third-party sign-in (Google, Facebook, and the like), Apple expects an equivalent option that limits data collection, and Sign in with Apple is the accepted one. Why: the user should be able to create an account without handing a third company their identity.

3. Account deletion.

   If your app lets someone create an account, it must let them delete it from inside the app, not by emailing support. Why: the person who made the data should be able to remove it without a negotiation.

4. Restore purchases.

   If you sell anything that persists (a non-consumable or a subscription), the app needs a working way to restore it on a new device. Why: a person who paid should never be asked to pay again because they changed phones.

It has to work, all of it, on the day you submit.

1. Demo login that works.

   If the app needs an account, review needs one that is live, with the credentials in the review notes. A broken demo login is an instant return. Why: the reviewer cannot approve what they cannot open.

2. No coming soon.

   Placeholder screens, features marked coming soon, and empty states that lead nowhere are treated as an unfinished app. Why: the store lists finished products; the review is not a beta program.

3. No broken links.

   Every link in the app and the listing (privacy policy, support, terms) has to resolve. Why: those links are the user's recourse, and a dead support link means there is none.

4. Not just a website.

   An app that is a web page inside a frame with nothing native about it is judged on minimum functionality. Why: the store is for apps; the browser already exists.

5. iPad is not optional.

   If your app installs on iPad, the reviewer opens it on iPad. Stretched layouts, cut-off buttons, and portrait-only screens that break in landscape are all returns. Why: it is the same app in the same store; it has to work on both.

The listing has to tell the truth, and users need a way to speak.

1. Screenshots that match the app.

   Outdated screenshots, features that no longer exist, or screens from a different version are metadata problems. Why: the screenshot is the promise; the app is the product; they have to be the same thing.

2. Paid features shown without saying so.

   If a screenshot shows a feature that requires a purchase, the listing needs to make that clear. Why: a person should know what is free before they download.

3. A way to report.

   If users can post, message, or share anything, the app needs a way to report content, block a person, and reach you. Why: the person on the receiving end of abuse needs a button, not a search for your email.

Look at it the way the reviewer will.

• Know which side of the payment line your product is on before you write a checkout.
• Every account feature has a delete path inside the app.
• A demo account exists, works today, and is in the review notes.
• Nothing says coming soon. Every link resolves.
• Open it on an iPad and use every screen.
• Screenshots are from this build, and paid features are marked as paid.
• If users can post or message, there is report, block, and contact.

This guide is the what and the why. The Pro pack is the reviewer's full checklist with the guideline references, the review-notes template, and the response templates for when something comes back. The App Review Auditor is the agent that opens your project, checks every item against your actual screens and code, and fixes what you tell it to fix.

Describe it honestly.

Four questions the reviewer will answer about you. Entries stay on this page and are not sent anywhere.

A readiness read from a plain description.

Paste a plain description of your app. It tells you which of the twelve rules apply, which ones you are likely to trip, and what to check before you spend time on submission.

I am preparing an iOS app for App Store review. From my description, tell me which of these twelve areas apply to my app and, for each that applies, whether I am likely to pass or fail, and the one question I should answer before submitting. Do not tell me how to build anything. Explain what the rule is and why Apple has it.

Areas: payments inside the app (digital versus physical), Sign in with Apple when third-party sign-in exists, account deletion inside the app, restore purchases, demo login for review, coming soon or placeholder screens, broken links, website-in-a-frame apps, iPad layout, screenshots matching the current build, paid features shown in screenshots without disclosure, report and block for user content.

End with: the three areas most likely to send my app back, in order.

MY APP:
[what it does, how people pay, whether there are accounts, what users can post, which devices it runs on, what is unfinished]

One prompt. Paste it into Claude. It builds the whole thing for your business.

The Pro pack is a build prompt with blanks for your context: your product, your medium, your team. Fill them in, answer its questions, and it produces the complete system in your words. The PDF explains the method so you can judge the output. The reviewer's forty-item checklist with the guideline behind each item, the payment decision tree, the review-notes template, the screenshot rules, and the response templates for when something comes back.