App Store submission requirements are mostly paperwork rather than code. Apple’s own reference marks more than a dozen properties as required across the app record, the version, privacy and pricing, and the store will not take a submission without privacy answers, a reachable policy URL, and a way for users to delete their account if the app supports account creation.
Two different things get called requirements. One is the toolchain minimum, the SDK and Xcode version a build has to be compiled against before App Store Connect will accept the upload. This page is about the other one: the fields, files and in-app behaviors that decide whether a submission is accepted for review at all. If your build is already uploaded and sitting there, the toolchain question is answered and this is the list still in front of you.
Owners who paid for an app brace for the build to be the hard part. Nobody warns a first-time owner that the submission is where the weeks go. Twelve of the fourteen rows below are filled in outside the app, and several of them nothing will produce for you.
Everything here comes off a page Apple or Google publishes, read on 16 August 2026, with each page named where its requirement appears. This page does not narrate a submission I ran.
Two adjacent jobs stay off it. If Apple has already bounced you and you need which guideline number Apple cited, and what each one asks you to change, that mapping lives on its own page and no number gets re-explained here. Access control, backups, error alerting and payment verification are the checks App Review never looks at, and clearing this pass says nothing about any of them. If you want the whole route rather than the pre-flight, the sequence that takes a signed build through the store record and out to customers is a separate walkthrough.
What the App Store submission itself requires
Every row below is a thing a submission needs, where inside App Store Connect or the app it lives, and what your build tool actually hands you. That third column is the one nobody publishes. It is a judgement about a class of tool rather than a promise about any named builder’s screen, and it comes from working on apps whose owners did not write the code.
| What the submission needs | Where it lives | What a build tool gives you | What it costs you if it is missing |
|---|---|---|---|
| App name, up to 30 characters | App record | Nothing. A project name is not a store name, and the store name has to be free | The record cannot be created |
| Bundle ID | App record | A generated identifier inside the project, which the record has to match exactly | The build never attaches to the version |
| SKU | App record | Nothing. It is your own internal reference and Apple never shows it | The record cannot be created |
| Primary language and primary category | App record | Nothing | The record cannot be created |
| Age rating | App record | Nothing. No generator answers a questionnaire about your content | The submission cannot go in |
| Icon and screenshots | Product page | In projects I have reviewed, the usual output was a placeholder icon rather than finished screenshots | The listing stays incomplete and unsubmittable |
| Description, plus keywords capped at 100 characters (Apple publishes that limit two ways) | Product page | In projects I have reviewed, generated listing copy was usually generic rather than search-led | The listing stays incomplete |
| Support URL | Version | In projects I have reviewed, a reachable support page was often absent | A dead URL reads as unfinished metadata to a reviewer |
| Privacy policy URL | App privacy | A default page describing the builder’s product rather than your app | Required field, and the in-app link is required separately |
| Privacy answers about the data your app collects | App privacy | Nothing, and the answers have to cover third-party code you never chose | The submission cannot go in |
| Permission purpose strings | Inside the app | Defaults, or entries for a feature the app does not have | The string stops the submission even when the feature is fine |
| Account deletion, started inside the app | Inside the app | In projects I have reviewed, the complete flow was not produced by default | Any app with sign-up is blocked |
| Demo account or approved demo mode, plus review notes | App review information | Nothing. Seeded test users are not review credentials | The reviewer sees a login wall and stops |
| In-app purchase products, each with a review screenshot | App record and version | Mock purchase screens with no real product behind them | The purchase item is unreviewable |
The Apple pages behind those rows, all read 16 August 2026: which properties App Store Connect treats as required comes from Apple’s required, localizable, and editable properties reference; the name and keyword limits from Creating your product page; the privacy answers and what they have to cover from App privacy details on the App Store; account deletion from Apple’s account deletion support page; and the demo, purpose-string and in-app-purchase rules from the App Review Guidelines. Screenshots have exact pixel sizes per device class, which is a job of its own and worth settling before you start filling anything in.
The pre-submit pass, in the order the form asks for it
Work down this in order. App Store Connect will let you skip around and then refuse the submission for the one thing you left, so the order below is the order that stops you doubling back.
- 01 Confirm the store name is free and fits, and that the bundle ID in the record matches the one compiled into the build
- 02 Answer the age-rating questionnaire honestly about the content your app can actually show, including anything user-generated
- 03 Put a real privacy policy at a URL that loads, and link it inside the app as well as in the record
- 04 Answer the privacy questions for every data type your app and its libraries collect, not just the ones you wrote code for
- 05 Point the support URL at a page a stranger can reach you through, and open it yourself in a browser that is not signed in
- 06 Open the app and find the account deletion option as a new user would, if the app has sign-up at all
- 07 Create a demo account that works today, on the live backend, and write it into the review notes with anything non-obvious about reaching the main feature
- 08 Read every permission prompt string out loud and rewrite any that names a platform placeholder instead of your feature
- 09 Check that every in-app purchase you configured is visible and buyable inside the build you are submitting
- 10 Clear the export-compliance prompt so the upload stops asking on every build
- 11 Set price and availability, and decide whether the approved version releases automatically or when you say so
- 12 Open the listing preview and read it as a stranger, because inaccurate metadata is judged against what the app does
Two of those repeat work that a beta build already asked of you, and deliberately so: the demo account and the export-compliance prompt both come back at submission. If you have not been through that stage yet, the beta build pass before any of this covers the upload path, the build statuses and the compliance key by name, and this page does not re-teach either.
The app privacy answers, and why a builder’s app has more of them than you think
The privacy questions are not a checkbox. Apple’s App privacy details page puts you on the hook for code you did not choose: the answers have to describe what any library inside the app collects, not only what somebody wrote for you. You are declaring, under your own name, what code you have never read sends where.
Generated apps carry more of that code than their owners expect. Analytics that arrived with a template, an error reporter switched on by default, an auth library that phones home, a payment SDK: each one collects something and each one belongs in your answers. Make whoever built the app write down every library it links against and what each one sends, before you touch the form.
Apple is explicit that the answers stay yours to maintain. “You’re responsible for keeping your responses accurate and up to date. If your practices change, update your responses in App Store Connect.” The same page grants the compensating freedom: “You may update your answers at any time, and you do not need to submit an app update in order to change your answers.” So a wrong answer discovered after launch is a fix you can make that afternoon, which is not true of most fields on this page.
There is a related file that lives in the build rather than the form. A privacy manifest declares the reason your app calls certain APIs, and a missing one fails the upload before any human sees it. That belongs to the beta-upload stage linked above, because it is a build defect rather than a missing answer on a form.
The privacy policy and support URLs your submission needs
Two URL fields decide more submissions than their size suggests. Apple’s privacy guidelines put the policy requirement in two places at once: “All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner” (App Review Guidelines, 5.1.1(i), read 16 August 2026). The field alone is half the requirement. An owner who pastes the URL into App Store Connect and never adds the in-app link has met one of two conditions.
The policy itself has to be about your app. A builder’s default page describes the builder’s product, a different company collecting different data for different reasons. Apple’s guidelines require the policy to identify what data the app collects, how it collects it, and every use of that data, and to confirm that any third party you share user data with protects it to the same standard. A generic page fails all three and is checkable in a minute by anyone reading it.
I am not going to pretend this page can write your policy. Find out what your app collects first, because a policy written before that question is answered will be wrong.
The support URL costs less and gets missed more. It is a required property, and a support page that returns a 404 lands squarely in what Apple asks of submissions: final versions “with all necessary metadata and fully functional URLs included” (App Review Guidelines, 2.1(a), read 16 August 2026). A page with your email address on it satisfies this. Ten minutes of work sits between a lot of people and a resubmission.
Account deletion: the requirement builders may leave out
This is the most reliable blocker on the list for an AI-built app, and the one missing from the community lists that rank for this query. Apple’s rule: “Starting June 30, 2022, apps submitted to the App Store that support account creation must also let users initiate deletion of their account within the app.”
If the app has sign-up, it needs delete-my-account. In the apps I have reviewed, builders did not generate that full deletion flow by default. Sign-up, log-in and password reset arrive as a bundle from an auth library; deletion does not, because deletion is a question about your own data model. The tool has no way to know which rows belong to a user, which ones have to survive for legal reasons, and which ones break a foreign key on the way out. Owners reach this line with a finished app and find that the thing standing between them and a submission is a feature nobody built.
Apple closes the two obvious shortcuts explicitly. “Offer to delete the entire account record, along with associated personal data. You may include additional options, but only offering to temporarily deactivate or disable an account is insufficient.” A disable flag on the users table is not compliance. And if the deletion actually finishes on your website, the app still has to start it: “If people need to visit a website to finish deleting their account, include a link directly to the page on your website where they can complete the process.”
Read plainly, that makes this a build task. Somebody has to write a settings entry, a confirmation step, and a server path that removes the account record and the data hanging off it. Budget for it as work, not as a form field, because it is the item on this page most likely to send an owner back to whoever wrote the app.
Demo credentials and what to put in review notes
App review information is a required property, and the reviewer’s experience of your app is decided entirely by what you put in it. If there is a login, a working account goes in the notes. A seeded test user from a fixture file will not do, and neither will an account that last worked in staging. Use one you signed into today, on the live backend, from a device.
Apple allows one alternative and attaches a condition most people miss. “If you are unable to provide a demo account due to legal or security obligations, you may include a built-in demo mode in lieu of a demo account with prior approval by Apple. Ensure the demo mode exhibits your app’s full features and functionality” (App Review Guidelines, 2.1(a), read 16 August 2026). Prior approval means before submission, not as an explanation attached to it, and a demo mode that shows a stripped-down tour of the app does not qualify.
The notes field is also where non-obvious things go. Apple asks that new features and product changes be described specifically in the Notes for Review section, and says generic descriptions get rejected. If the main feature is three taps deep, or needs a QR code, or only appears after data exists in the account, say so there. A reviewer who cannot reach the thing your listing advertises has to assume it does not work.
Permission strings, in one paragraph
Every sensitive permission your app requests carries a string the user reads in the prompt, and Apple’s rule for it is one line: “Ensure your purpose strings clearly and completely describe your use of the data” (App Review Guidelines, 5.1.1(ii), read 16 August 2026). Generated apps fail this two ways. Some ship the tool’s placeholder text, which describes nothing. Others declare a permission for a feature that was prompted, half-built, and never removed, so the app asks for the camera and never opens it. The exact permission entries a generated build emits, and which ones Apple bounces, are a subject of their own, and this page stops at the rule.
If the app charges money
Purchases are a submission requirement before they are an implementation problem. Each in-app purchase is its own record with its own required fields, including a review screenshot, and the guidelines are direct about the rest: “If you offer in-app purchases in your app, make sure they are complete, up-to-date, visible to the reviewer and functional. If any configured in-app purchase items cannot be found or reviewed in your app, explain the reason in your review notes” (App Review Guidelines, 2.1(b), read 16 August 2026).
That is where the paperwork and the code meet badly in some generated apps. A builder may produce a pricing page, a plan comparison, and an upgrade button without connecting the purchase to Apple’s payment system. Verify the current build before assuming either that the native purchase exists or that the builder cannot produce it. So the configured product may exist in App Store Connect while the button in the app reaches nothing. Wiring a real subscription into an app without one is its own piece of work, and it is worth knowing that before you configure the products.
What Apple’s reference marks required, and what it marks editable at any time
This is the half of the list that decides whether a mistake costs you a click or a release. Apple’s properties reference says what it covers: “The tables below show the app and version properties required for App Store submission. The tables also indicate the properties that can be localized and edited at any time without submitting a new version of your app.”
Read the two columns literally and no further. A property Apple marks editable can be changed on a live app whenever you like. A property Apple leaves blank is one Apple is not promising you can change that way, which is not the same as Apple saying it is fixed. Here is that split for the fields a first submission actually touches, read from the reference on 16 August 2026.
| Property | Apple marks it required | Apple marks it editable at any time |
|---|---|---|
| Name | Yes | No |
| Subtitle | No | No |
| Bundle ID | Yes | No |
| SKU | Yes | No |
| Content Rights | Yes | No |
| Age Rating | Yes | No |
| Primary Category | Yes | No |
| Secondary Category | No | No |
| Primary Language | Yes | Yes |
| Support URL | Yes | No |
| Marketing URL | No | No |
| Privacy Policy URL | Yes | No |
| Data Types, the privacy answers | Yes | Yes |
| Copyright | Yes | Yes |
| App review information | Yes | Yes |
| Price and App Availability | Yes | Yes |
The surprise in that table is the URL rows. A support or privacy policy URL looks like the kind of thing you can swap whenever you like, because it is only a link. Apple does not mark the support and privacy policy URLs editable at any time, which surprises most people. Pick the URLs you can keep, and host the pages somewhere you control rather than on a platform you might leave.
The one thing this table does not tell you is who owns the account all of it lives in. Whose name the account is in, and how to let a helper work inside it without handing it over, is a decision to make before the record exists rather than after. The character limits on the name, subtitle and description, what changing a name or a category actually takes once you have submitted, and why a bundle ID is permanent, all sit alongside it on a page of their own.
The same pass on Google Play, in short
Play asks for the same kind of thing in a different shape, and three items have no Apple equivalent. The Data safety form is a declaration you complete in Play Console about what the app collects and shares, and Google requires it to account for third-party libraries and SDKs inside the app as well as the code written for you (Google on the Data safety section, read 16 August 2026). A content rating comes from a questionnaire rather than a self-assessment. And a new personal developer account has to run a closed test with a set number of testers, held for an unbroken stretch, before production access opens at all (Google’s testing requirements, read 16 August 2026).
That last one is a scheduling problem rather than paperwork, and it catches anyone who assumed both stores fit in one week. The Play side of the same pass, including the data safety form and the testing track, is a walkthrough of its own, and almost nothing from the Apple path transfers.
What this pass does not cover
Getting everything above right does not mean approval. It means the submission is complete enough to be reviewed, and review is a judgement about your app made by a person, against rules this page deliberately does not map.
Five neighbouring jobs start where this one ends. An app that gets fixed, resubmitted and bounced again has fallen into a pattern with its own diagnosis, and a first-submission list will not break it. What the review queue does with a submission once it goes in, and how to tell a slow wait from a stalled one, is worth knowing before you start refreshing the status. A release build that crashes where the tested one did not is a post-approval failure with its own causes. The exact pixel sizes each store wants for screenshots and icons are a job to settle before the listing. And what a first publish actually costs, once the program fees stop being the whole bill, adds up in places this list does not touch.
Two other lists get confused with this one often enough to name. A web go-live pass covers domains, hosting, monitoring and the things that break when strangers arrive at a website, and none of it is a store submission. Launch-day preparation for a traffic spike from a listing site is about surviving attention, and App Review will never see it.
The loose end I would leave you with: nothing on this page tells you whether the app underneath the paperwork is any good. A complete submission and a fragile app look identical from App Store Connect.
Common questions about App Store submission requirements
What are the guidelines for submitting apps to the App Store?
Apple publishes one document, the App Review Guidelines, covering safety, performance, business, design and legal rules. Submission requirements sit inside it alongside the App Store Connect properties reference and Apple’s account deletion and privacy pages. Which specific rule applies to a rejection is a separate question from what a first submission has to contain.
The practical answer for a first submission is that the guidelines rarely stop you; the missing fields do. Read the completeness and privacy sections, then work down the list on this page.
What does Apple actually require before I can submit?
More than a dozen properties are marked required, including these: on the app record, name, bundle ID, SKU, primary language, primary category, age rating and content rights; on the version, support URL, version number, copyright and review information; on privacy, the policy URL and data types; and on pricing, availability, price and dates.
On top of the fields, the app itself has to allow account deletion if it has sign-up, and the reviewer has to be able to get in.
Do I need a privacy policy to publish an app?
Yes, and in two places. Apple requires the policy URL in the App Store Connect metadata field and a link inside the app in an easily accessible manner. The policy has to describe what your app collects, how, and every use of the data, including anything third-party code in it sends.
A builder’s default policy page describes the builder’s product rather than yours and does not meet the requirement.
Does my app need an account deletion option?
If the app supports account creation, yes. Apple requires apps to let users initiate deletion of their account inside the app, and offering only to deactivate or disable an account is explicitly insufficient. If the process finishes on your website, the app has to link straight to the page that completes it.
In the apps I have reviewed, builders did not produce this complete deletion flow by default, so verify the current build and treat any missing pieces as real implementation work.
What do I put in the demo account field if my app has a login?
A username and password for an account that works today on the live backend, plus anything non-obvious a reviewer needs to reach the main feature. Where legal or security obligations rule out a demo account, Apple allows a built-in demo mode instead, but only with prior approval and only if it shows the full app.
Test the credentials on a device before you submit them.
Are the requirements different on Google Play?
Yes, in shape rather than spirit. Play asks for a Data safety form covering third-party libraries, a content rating from a questionnaire, and, for a new personal developer account, a completed closed test before production access opens. The privacy policy requirement exists on both stores.
Plan them as two separate jobs rather than one submission done twice.
When every fix and release still depends on you
AxonBuild can trace the failure, repair the broken workflow, and ship the next change without rebuilding the parts that already work.
