Every app on the App Store, and every update, is checked by people at Apple against one document: the App Store Review Guidelines. You don’t need to memorize it. You need to know its shape, and the few rules worth checking closely before you submit.
The short version
The guidelines have five sections: Safety, Performance, Business, Design and Legal. Five areas are worth checking closely before you submit: completeness (2.1), metadata (2.3), in-app purchase (3.1.1), spam and copies (4.3), and privacy (5.1.1). Apple’s own figure covers only the first: on average, more than 40% of unresolved issues relate to 2.1. When you are rejected, fix and resubmit, or reply to App Review in App Store Connect. Appeal only if that fails.
Apple last updated the guidelines on October 16, 2026. The section summaries below are our plain-language paraphrase, not Apple’s wording. Only text in quotation marks is Apple’s.
How the guidelines are organized
Apple opens with its principle: “we want to provide a safe experience for users to get apps and a great opportunity for all developers to be successful.” Then come five sections, then a short checklist for before and after you submit. In plain language, the five sections cover:
1
Safety
Content, user-generated content, kids, physical harm, contact details and data security.
2
Performance
Whether the app is complete, tested, accurately described and built on public APIs.
3
Business
How you charge: in-app purchase, subscriptions, other purchase methods.
4
Design
Original, useful, app-like. No copycats, no repackaged websites, no spam.
5
Legal
Privacy, intellectual property, gambling, VPNs and the developer code of conduct.
1. Safety
In plain language, section 1 is about not hurting people. Apple puts it simply: if you’re looking to shock and offend people, “the App Store isn’t the right place for your app.”
- 1.1 Objectionable content. No defamatory, discriminatory or mean-spirited content, and nothing “intended to disgust.”
- 1.2 User-generated content. If people can post or generate content, including through AI content creation, you need ways to filter, report and block.
- 1.3 Kids. Apps in the Kids category have extra rules on links out, purchases, third-party ads and analytics, and data.
- 1.4 Physical harm. Medical apps that could give inaccurate data get closer scrutiny.
- 1.5 Developer information. The app and its support URL must include an easy way to contact you.
- 1.6 Data security. Handle user information securely.
2. Performance
In plain language, section 2 asks whether the app works and is described honestly. It includes 2.1, the guideline Apple links to more than 40% of unresolved issues.
- 2.1 App completeness. Submit final versions, tested on device, with working URLs and no placeholder text. If the app has a login, include demo account details, “and turn on your back-end service!”
- 2.2 Beta testing. Demos and betas belong on TestFlight, not the App Store. See our TestFlight guide.
- 2.3 Accurate metadata. The description, screenshots, previews and privacy information must reflect the app’s core experience.
- 2.4 Hardware compatibility. iPhone apps should run on iPad whenever possible, and use power efficiently.
- 2.5 Software requirements. Use only public APIs, and run on the currently shipping OS.
3. Business
In plain language, section 3 is about money. If your business model isn’t obvious, explain it in the metadata and review notes; Apple says confusion “will delay your review and may trigger a rejection.” Apple also says it won’t distribute apps and in-app purchase items that are “clear rip-offs,” and will reject expensive apps that try to cheat users with irrationally high prices. It adds that manipulating reviews or rankings can get you expelled from the Developer Program.
- 3.1.1 In-app purchase for unlocking digital features or content.
- 3.1.2 Subscriptions must provide ongoing value.
- 3.1.3 Other purchase methods for specific cases, such as reader apps and person-to-person services.
- 3.2 lists other acceptable and unacceptable business models.
4. Design
In plain language, section 4 sets the minimum bar for an app worth having. Apple calls these “minimum standards for approval.”
- 4.1 Copycats. “Come up with your own ideas.” Don’t copy another app’s name or UI.
- 4.2 Minimum functionality. Apps should include “features, content, and UI that elevate it beyond a repackaged website.” A web app in a thin wrapper risks falling short of this rule; Apple judges the features, content and UI, not the technology. See our Lovable alternatives for iOS apps.
- 4.3 Spam. No duplicate apps, no variants of crowded categories without something new.
- 4.8 Login services. If you use a third-party login such as Google Sign-In for the main account, also offer an equivalent option that limits data to name and email and lets people keep their email private.
- 4.10 You may not charge for built-in capabilities like push notifications or the camera.
5. Legal
In plain language, section 5 is about the law. It starts: apps “must comply with all legal requirements in any location where you make them available.”
- 5.1 Privacy. Privacy policy, permissions, data minimization, account deletion, and sharing with third parties.
- 5.2 Intellectual property. Only use content you created or have a license to use.
- 5.3 Gaming, gambling and lotteries. Heavily regulated; expect extra review time.
- 5.4 and 5.5 cover VPN apps and mobile device management.
- 5.6 Developer code of conduct. Be respectful, including in your replies to App Review.
Five areas to check before submission
These five are an editorial choice: rules that are easy to miss and well documented by Apple. Apple publishes a figure only for the first.
2.1 App completeness
Apple’s App Review page says that, on average, more than 40% of unresolved issues relate to Guideline 2.1. It covers crashes, placeholder content, broken links and incomplete review information.
- Test the release build on real devices running the latest iOS.
- Replace every “Lorem ipsum”, test image and empty screen.
- Check that the support link and privacy policy link work.
- In App Review Information, add a working demo account and any steps a reviewer needs.
- Keep your backend running during review.
2.3 Accurate metadata
Your store page must describe the app you actually ship.
- 2.3.1 New features must be described “with specificity” in the review notes; generic descriptions are rejected.
- 2.3.3 Screenshots should show the app in use, “not merely the title art, login page, or splash screen.”
- 2.3.7 App names are limited to 30 characters. Don’t pack metadata with trademarked terms, popular app names or prices.
- 2.3.8 Icons, screenshots and previews must suit a 4+ age rating, even if the app is rated higher.
3.1.1 In-app purchase
If people pay to unlock features or content inside the app, such as subscriptions, premium content or a full version, you must use in-app purchase. You can’t use your own unlock mechanisms like license keys or QR codes. Physical goods and services used outside the app are the reverse: Guideline 3.1.3(e) says those must use other payment methods, such as Apple Pay or a card.
The United States storefront is different
For apps on the United States storefront, Guideline 3.1.1(a) says the entitlements for linking to other ways of buying digital content or services are not required for buttons, external links or other calls to action. That is a narrow exception, not a general pass: the rest of section 3.1 still applies, other storefronts have different rules, and Apple changes these terms by region and entitlement. Read the current text for each storefront you sell in before you design a paywall.
4.3 Spam
Two things trigger it. First, multiple Bundle IDs for the same app, such as a separate app for each city; Apple suggests one app with in-app purchase for the variations instead. Second, apps “indistinguishable from what’s already widely available.” Apple names dating, flashlight, sound effects, wallpaper, simple timers and fortune telling as well established, and won’t accept new ones “unless they offer a meaningfully different or improved experience.” If you are entering a crowded category, say in the review notes what is different.
5.1.1 Data collection and storage
The privacy rule with the most parts:
- (i) Privacy policy. Link it in App Store Connect and inside the app. It must say what you collect, how, why, who you share it with, and how people can delete their data.
- (ii) Permission. Get consent before collecting user or usage data, give people an easy way to withdraw it, and write purpose strings that clearly describe why you need the data.
- (v) Account sign-in. If the app has no significant account-based features, let people use it without logging in. If people can create an account, they must be able to delete it inside the app.
This one catches real apps. Canistr, the film app Irohas Photo built with AirBuild, was rejected under 5.1.1(v) on its first version. It was rejected before lunch; AirBuild fixed the issue and resubmitted it after lunch. Read the Irohas story.
Guideline 5.1.2(i) adds one more line many AI apps need: you must “clearly disclose where personal data will be shared with third parties, including with third-party AI,” and get explicit permission first. The App Privacy answers in App Store Connect must match all of this; our App Store Connect guide shows where they go.
When the review doesn’t go your way
If a submission doesn’t pass, you get a message in the App Review section of your app in App Store Connect. Many developers still call this the Resolution Center. It names the guideline and describes the issue.
Read the cited guideline
Open the guideline number in the message and read the full text, not only the summary.
If the issue is real, fix it and resubmit
Upload a new build if the code changed, or update the metadata if it didn’t. Say what you changed in the review notes.
If something is unclear, reply to App Review
Click Reply to App Review in App Store Connect. Apple says a specialist familiar with your app will reply. Be specific: the exact feature, guideline or step. You can also ask for a call; Apple says calls are typically completed within three to five business days.
If you still disagree, appeal
File an appeal with the App Review Board. Apple asks you to reply to the rejection first, to submit only one appeal per rejected app, and to address every cited guideline in that one appeal, point by point.
Don’t mix up the channels
Apple says not to use Reply to App Review to appeal or to request an expedited review, and not to file an appeal for a status update. Each has its own form.
Two more options are worth knowing. If you submit a bug-fix update and the reviewer finds other issues, Apple may offer to approve the current submission and let you fix the rest next time, as long as there are no legal or safety concerns. And before you submit, you can book a 30-minute video appointment with App Review to ask about the guidelines.
Expedited review
Apple says App Review typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. If you can’t wait, you can request an expedited review in two cases:
- A critical bug fix. Put the steps to reproduce the bug on the current version in the Notes field when you submit.
- An event-related release. Include the event, its date and how your app is associated with it. Apple recommends scheduling the release ahead of time instead.
Only apps already submitted can be expedited, and Apple asks that requests be “reserved for matters of genuine urgency.” Use the Request an Expedited App Review form.
Before you submit
Apple’s own checklist comes down to four lines: test for crashes and bugs, make the metadata complete and accurate, keep your contact details current, and give App Review full access, with a demo account if the app needs sign-in. Then choose Add for Review and, in the draft submission, Submit for Review. Our guide to making an app with AI puts this in the order you’ll meet it.
AirBuild handles this loop for you. On Basic, Plus and Ultra, it prepares the App Store listing, screenshots and review notes, submits your app, tracks the review, replies to App Review feedback, fixes issues and resubmits.
Frequently asked questions
What are the App Store Review Guidelines?
They are Apple’s rules for apps on the App Store, in five sections: Safety, Performance, Business, Design and Legal. Every submission, including updates, is reviewed against them.
What is the most common reason apps are rejected?
Apple does not publish a full ranking of rejection reasons. Its App Review page says that, on average, more than 40% of unresolved issues relate to Guideline 2.1, App Completeness. That covers crashes, placeholder content, broken links and missing review information such as a demo account.
How do I respond to an App Store rejection?
Read the message in the App Review section of the app in App Store Connect. If the issue is real, fix it and resubmit. If you have a question or think the reviewer misunderstood the app, reply to App Review there with specifics. Appeal to the App Review Board only after that.
Can a tool handle an App Store rejection for me?
Many AI app builders stop at submission, and you answer App Review yourself. AirBuild also handles what comes after: it replies to App Review feedback, fixes the issue and resubmits, from the Basic plan up. Canistr, the film app Irohas Photo built with AirBuild, was rejected under 5.1.1(v) on its first version; AirBuild fixed the issue and resubmitted it the same day. You still need your own Apple Developer account.
How long does App Review take?
Apple says App Review typically reviews at least 50% of submissions in less than 24 hours and 90% in less than 48 hours. Complex apps or repeated rejections for the same issue can take longer. If your app is stuck in Waiting for Review, see what to check before you chase Apple.
Can I speed up App Review?
You can request an expedited review for a critical bug fix or a release tied to an event, after the app has been submitted. Apple asks that these requests be reserved for genuine urgency.