App Store submission guidelines: what to check before Apple reviews your app

Most App Store rejections aren't about clever policy edge cases. They're about a demo account that expired, a backend that was switched off for the weekend or a screenshot of a login screen. Apple's 2025 App Store Transparency Report counts 9,100,620 app submissions reviewed and 2,093,244 rejected. Performance guidelines, the section that covers completeness, metadata and technical basics, were cited in 1,354,418 of those rejections.

So the App Store submission guidelines are less a rulebook to memorize than a checklist to run before you press Submit. This guide walks through that checklist in the order App Review meets your app. It's built from Apple's App Review Guidelines (last updated October 16, 2026) and the App Store Connect help pages, with guideline numbers so you can check the source yourself.

Before you start: what the App Store submission guidelines assume you have

Get these in place before you upload a build.

• A paid developer account. The Apple Developer Program costs 99 USD per membership year, or local currency where available. You can enroll as an individual or as an organization. Organizations need a D-U-N-S Number, a public website and a work email on the company's domain, according to Apple's enrollment requirements.
• The right entity for regulated apps. Banking, healthcare, gambling, air travel and crypto exchange apps should be submitted by the legal entity that provides the service, not an individual developer (guideline 5.1.1(ix)). If an agency builds the app, plan for it to be submitted from the client's account.
• A current SDK. Apple raises the minimum SDK regularly. Since April 28, 2026, uploads must be built with Xcode 26 or later and the iOS 26 SDK or later. Since September 9, 2026, iOS and iPadOS apps must target iOS 13 or later. Apple's Upcoming Requirements page lists each change, and its submitting page says that from April 2027 the floor moves to the iOS 27 SDK and iOS 15.
• EU trader status, if you sell in the EU. Apps without verified trader status under the Digital Services Act are removed from the EU storefronts until it's provided.

Step 1: Make the build complete enough to review

App Completeness (guideline 2.1) is where most avoidable rejections live. Apple's App Review page says that, on average, over 40% of unresolved issues relate to guideline 2.1. That's crashes, placeholder content and missing information, not policy disputes.

The fixes are mundane, which is exactly why teams skip them:

1. Test on real devices running the latest OS. Binaries that crash or show obvious technical problems are rejected.
2. Scrub placeholder content. No lorem ipsum, empty web pages, "coming soon" tabs or dead URLs. Every link has to work, including your support URL and privacy policy.
3. Give the reviewer full access. If the app has a login, include an active demo account in the App Review Information section. If legal or security rules prevent that, a built-in demo mode is allowed with Apple's prior approval.
4. Leave the backend running. Reviewers test against your live services. A staging server that sleeps at night produces a rejection by morning.
5. Make in-app purchases findable. Every configured purchase must be complete, visible to the reviewer and working. If one can't be reached, explain why in the review notes (2.1(b)).
6. Explain anything non-obvious. Hardware dependencies, location-specific features and unusual flows belong in the review notes. Apple says vague notes for new features will be rejected (2.3.1(a)). If a feature needs hardware the reviewer won't have, be ready to send a demo video or the device.

Betas don't belong in the store at all. Demos, betas and trial versions go through TestFlight (guideline 2.2). TestFlight lets you add up to 100 internal testers and invite up to 10,000 external testers. The first build you share externally needs TestFlight App Review, so submit that build well before you need outside feedback.

Step 2: Write metadata that matches the app

Guideline 2.3 asks for one thing: the product page should describe the app people actually download. Reviewers compare the two.

Start with the field limits in App Store Connect:

Source: App Store Connect help, app information and platform version information.

A few more metadata rules catch experienced teams:

• Assets must suit a 4+ audience, even if the app is rated higher (2.3.8). A violent game still needs screenshots that don't show a gruesome death.
• "For Kids" and "For Children" are reserved for the Kids Category.
• No other platforms in your metadata. Android logos, "also on Google Play" badges and alternative marketplace names are out unless there's approved interactive functionality (2.3.10).
• Use fictional account data in screenshots and previews, never a real customer's details (2.3.9).
• Pick the category that fits, not the one with lighter competition. Apple may change it for you (2.3.5).

Publishing on Android as well? Our guide to publishing an app on Google Play covers that store's account, testing and review steps.

Step 3: Meet Apple's screenshot and app preview video requirements

Screenshots are required. App preview videos are optional, but if you add one, it has to meet a strict technical and content spec.

Screenshots

You need at least one and can upload up to 10 per device size, in .jpeg, .jpg or .png, with no transparency, per Apple's screenshot specifications. The page lists which iPhone display size is required and asks for a 13-inch iPad set if the app runs on iPad. Check it before each release, because the required sizes change as new devices ship. If your interface is the same across sizes, upload the largest required set and App Store Connect scales it down.

Content matters as much as pixels. Screenshots must show the app in use, not just title art, a login page or a splash screen (2.3.3). Text overlays and touch indicators are fine.

App preview video requirements

These are the specs from Apple's app preview specifications page:

Note the resolution row. App Store Connect accepts a set of standard resolutions per display size, not the phone's native screen resolution. Apple says to prepare the file at the accepted resolution, not the device resolution.

The content rules are where previews usually get rejected. Guideline 2.3.4 says previews may only use video screen captures of the app itself. Apple's app preview guidance adds the practical detail:

• Stay inside the app. No over-the-shoulder shots and no fingers tapping a screen.
• Plan for silence. Previews autoplay muted, so use on-screen text to carry the story. Narration is allowed as a bonus, not a crutch.
• Skip prices and dates. No specific prices and no seasonal references such as "new for spring".
• Disclose purchases. If you show features that need an in-app purchase, a subscription or a login, say so in the footage or the end frame.
• Choose the poster frame deliberately. It shows when autoplay is off. Changing it on an approved preview means submitting a new version of that preview.

You can capture footage by connecting your iPhone to a Mac and recording with QuickTime Player, then edit in iMovie or Final Cut Pro. Previews always play before screenshots on the product page, so they're the first thing a visitor sees.

Step 4: Get privacy, age rating and sign-in right

Legal guidelines, which include privacy, were cited in 495,673 rejections in Apple's 2025 report, second only to Performance. Most of the privacy work is paperwork that has to match the code.

Privacy policy, twice. Every app needs a privacy policy link in App Store Connect and inside the app (5.1.1(i)). The policy must say what you collect, how and why, and how users can revoke consent or request deletion. It must also confirm that third parties you share data with, including analytics tools and SDKs, protect it to the same standard.

Privacy details for the product page. App Store Connect asks for your data practices, including those of third-party code you include. Apple's submitting page says this information feeds the Privacy Nutrition Label and is required for new apps and updates. Since May 1, 2024, uploads also need approved reasons for certain APIs, including APIs called by third-party SDKs.

Permission prompts that explain themselves. Purpose strings must clearly describe why you need the camera, contacts or location (5.1.1(ii)). Ask only for data the core feature needs (5.1.1(iii)). Tracking across other companies' apps and websites requires App Tracking Transparency permission (5.1.2(i)).

AI features need their own disclosure. Guideline 5.1.2(i) now says you must clearly disclose where personal data is shared with third parties, including third-party AI, and get explicit permission first. If your chat feature sends user text to an outside model, the consent screen has to say so.

Account deletion inside the app. If users can create an account in the app, they must be able to start deleting it in the app too (5.1.1(v)). Apple's account deletion guidance allows a link to a web page that completes the process, as long as the link goes directly there.

Sign-in options. If you use a third-party or social login for the primary account, guideline 4.8 requires an equivalent option. It must limit data to name and email, let users hide their email and not track for ads without consent. Apps that only use your own company login, or enterprise and education apps that require an existing account, are exempt.

Age rating. Answer the age rating questionnaire in App Store Connect accurately (2.3.6). On devices running iOS 26 and later, Apple's age ratings are 4+, 9+, 13+, 16+ and 18+. The questionnaire now asks about capabilities such as user-generated content, messaging, advertising and age assurance, not just content themes. Kids apps carry extra rules, including limits on third-party analytics and advertising and compliance with laws such as COPPA (1.3, 5.1.4).

Step 5: Check your payment model against guideline 3.1

Apple asks you to explain any business model that isn't obvious in your metadata and review notes. If the reviewer can't work out how your purchases function, review slows down.

The core rules:

• Digital content and features use in-app purchase (3.1.1). That covers subscriptions, in-game currency, premium content and full-version upgrades. License keys, QR codes and crypto wallets can't be used to open up paid features.
• Physical goods and real-world services don't use in-app purchase (3.1.3(e)). A retail app sells shoes through Apple Pay or a card form, not through Apple's purchase system.
• One-to-one live services are flexible. Tutoring, consultations and fitness sessions between two people may use other payment methods (3.1.3(d)).
• Purchased credits can't expire, and restorable purchases need a restore mechanism.
• Subscriptions must last at least 7 days and work across the user's devices (3.1.2(a)).
• Loot boxes must show the odds of each item before purchase.

There's a US-specific change worth knowing. Under guideline 3.1.1(a), apps on the United States storefront don't need a special entitlement to link to other ways to pay. Buttons, external links and other calls to action are allowed there. Outside the US, that's still restricted to specific entitlements and storefronts. If your app sells in several countries, your purchase screens may need to differ by storefront.

Still choosing a model? Our comparison of in-app purchases vs ads weighs the tradeoffs.

Step 6: Clear the design bar on copycats, spam and minimum functionality

Section 4 is where Apple judges whether the app deserves a place in the store. Three rules do most of the work:

• Copycats (4.1). Don't clone a popular app's name, icon or interface. Using another developer's brand in your icon or name needs their approval.
• Minimum functionality (4.2). The app needs features, content and interface that take it beyond a repackaged website. A web view wrapped in a native shell with no device features is the classic rejection.
• Spam (4.3). Don't ship one app per city, franchise or client when a single app with in-app choices would do. Apple also won't accept new apps in saturated categories such as flashlights, simple timers and fortune telling unless they're meaningfully different.

In Apple's 2025 transparency report, Design guidelines were cited in 415,532 rejections. That category includes copycats, minimum functionality and spam.

Curating other people's content? The copyright rules that apply

News readers, video aggregators, recipe collections and "best of" apps all curate content someone else owns. The App Store submission guidelines treat that carefully, and App Review may ask you to prove your rights.

• Own it or license it (5.2). The app may only include content you created or have a license to use. The app should be submitted by the person or company that owns or has licensed the rights (5.2.1).
• Follow the source's terms (5.2.2). If your app uses or displays content from a third-party service, its terms of use must specifically permit that. Authorization must be provided on request.
• No unauthorized downloading (5.2.3). Apps can't save, convert or download media from sources such as YouTube, SoundCloud or Vimeo without explicit authorization. Even streaming can breach a service's terms.
• Curation alone isn't an app (4.2.2). Other than catalogs, apps shouldn't primarily be content aggregators, web clippings or a collection of links. Add search, personalization, offline reading or another real feature.
• Marketing assets count too. You're responsible for the rights to everything in your icon, screenshots and previews (2.3.9). Apple's preview guidance specifically names music, film, trademarked characters and brands.

Apple's App Review page says that if your app features third-party trademarks or copyrighted content, or lets users stream or download it, you should provide the authorization. Attach the license or partnership letter in the Attachment section of App Store Connect and mention it in the review notes. It saves a round trip with the reviewer.

If users add the content, guideline 1.2 applies. User-generated content apps, including AI content creation apps, must filter objectionable material, let people report it, let them block abusive users and publish contact details.

Step 7: Check the safety rules your category triggers

Most business apps never touch section 1, but a few categories get closer scrutiny:

• Health and medical apps (1.4.1) must disclose the data and method behind accuracy claims. Apps that claim to measure blood pressure or blood oxygen with phone sensors alone aren't permitted. Apps should also remind people to check with a doctor before making medical decisions.
• Every app needs reachable support (1.5). The app and its support URL need an easy way to contact you, with accurate details.
• Recording needs consent (2.5.14). Apps must ask permission and show a clear indicator when they record the camera, microphone, screen or other user activity.

After you submit: review times, rejections and appeals

Apple's App Review page says the team typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. Complex apps and repeat rejections for the same guideline take longer. Once approved, an app can take up to 24 hours to appear on every storefront you selected.

If you're rejected, the message in App Store Connect names the guideline. Reply there with the missing information first. Apple says that extra context may be enough to get the app onto the store. If you think the reviewer misunderstood the app, you can file one appeal per rejected submission with the App Review Board. For a bug-fix update to a live app, Apple won't hold the fix over unrelated guideline issues unless they're legal or safety concerns. You can also book a 30-minute video appointment with App Review to talk through the guidelines before you submit.

Two limits on any checklist, this one included. Apple calls its app submission guidelines a living document, and it says passing the Before You Submit list doesn't guarantee approval. Reread the guidelines before each major release, not just the first one.

If you want an engineer to check the build, metadata and privacy answers against these guidelines before Submit, our iPhone app development team can take that on. For apps that also need Android, web or backend work, see our mobile app development services.

FAQ

Where can I read Apple's official App Store submission guidelines?

Apple publishes them as the App Review Guidelines on its developer site, grouped into five sections: Safety, Performance, Business, Design and Legal. The page shows a "Last Updated" date, so check it before each release. Technical specs, such as screenshot sizes and metadata limits, live separately in App Store Connect Help.

Do the guidelines apply to apps distributed outside the App Store?

Partly. In some markets, iOS and iPadOS apps can be distributed through alternative app marketplaces or directly from a website after Apple's Notarization review. Notarization applies only a subset of the guidelines, and Apple's guidelines page has a filter that highlights which ones.

Can Apple remove an app that was already approved?

Yes. Apple says apps that stop working, offer a degraded experience or are no longer actively supported may be removed. Apps in saturated categories can be removed if they aren't updated or don't attract customers. Plan updates for each new iOS release, not just for new features.

Should I submit as an individual or as a company?

Submit as a company if you have a legal entity, and you must if the app is in a regulated field such as banking, healthcare or gambling. The organization's legal name appears as the seller on the App Store, and enrollment needs a D-U-N-S Number. VPN apps can only be offered by developers enrolled as an organization.

Related reading

Digital Transformation Challenges for the UAE and How to Solve ThemSeptember 30, 2026 · 10 min readEmbedded systems programming: how firmware is structured, written and testedJuly 28, 2021 · 12 min readeLearning management systems: 18 LMS platforms grouped by who you trainDecember 16, 2024 · 13 min read