What you need to submit an app

The hard part of a first submission is rarely the app. It is discovering, one rejected upload at a time, that the store wants eleven things you have not made yet. Here is the whole list for both stores, in the order it is worth doing.

Verified against Apple’s App Store Connect reference and Google Play’s graphic asset requirements on 29 August 2026.

The visual assets

These are the long pole. Everything else on this page is a form field you can fill in during an afternoon; the artwork is the part that needs a design decision.

Apple retired per-device uploads: supply the 6.9-inch iPhone master and, if you ship an iPad build, the 13-inch iPad master, and App Store Connect derives the rest. The exact tables are in the App Store screenshot sizes guide and the Google Play requirements guide.

The URLs

Three URL fields, and they are the ones that most often send a build back. Every one must resolve over HTTPS, without a login, from anywhere in the world — reviewers are not necessarily in your country and will not create an account to read your policy.

• Privacy policy URL — required by both stores, for every app, with no exception for apps that collect nothing. See the privacy policy URL guide for what the document has to say and where to host it.
• Support URL — required by Apple. A page with a contact route. An email address alone in a mailto: link is accepted less reliably than a real page.
• Marketing URL — optional on paper, expected in practice. A one-page site with your screenshots and a short pitch covers this and the support URL together.

The listing copy

Both stores index your title heavily, so the name field is doing real search work — see writing an App Store description that ranks. If you sell outside your own language, the localisation guide is worth reading before you write the English version, not after.

The forms nobody warns you about

• App Privacy answers (Apple). A questionnaire covering every data type your app or its SDKs collect, whether it is linked to identity, and whether it is used for tracking. Analytics and crash reporting count. The answers become the privacy label on your listing, and they must match what your privacy policy says.
• Data safety form (Google). Play’s equivalent, filled in separately in the Play Console, with the same rule: it must match both your policy and your actual SDK set.
• Age rating / content rating. A questionnaire on each store. Answer it honestly; an inaccurate rating is grounds for removal later, not just rejection now.
• Export compliance. Apple asks whether your app uses encryption. Almost every app that makes an HTTPS request does, and almost every one qualifies for the exempt category — but you have to answer.
• Demo account. If anything is behind a login, provide working credentials in App Review notes. A reviewer who cannot get past your sign-in screen rejects the build, and this is the single most common avoidable rejection.

A sane order to do it in

Most of this can be done before your build is finished, and doing it early turns a stressful launch week into a form-filling afternoon.

• 1. Register the app record and reserve the name — names are first-come and cannot be reserved indefinitely.
• 2. Publish the privacy policy and a support page. These need a URL that will not change.
• 3. Write the listing copy while the app is fresh in your head.
• 4. Take the raw captures and design the screenshot set — the slowest step.
• 5. Fill in App Privacy / Data safety once your SDK list is final.
• 6. Upload the build, attach the demo account, submit.

Before you press submit

A short pass that catches most of what review catches: open your privacy policy URL in a private window on mobile data. Sign out and try your demo credentials. Read your screenshots as a stranger and ask whether every screen shown actually exists in the build you uploaded. Check that no caption mentions a price, a competitor, or a platform the listing is not for. Then submit — and see why app screenshots get rejected if it comes back.