App Store Submission Checklist: Getting Through Review First Time

Store review is the part of an app project that nobody controls. You can, however, remove almost every reason for a rejection before you submit. This is the list we work through.

Before you can submit anything

Your own developer accounts

An Apple Developer Program membership (annual fee, and for a company you will need a D-U-N-S number, which can take a week or two to obtain) and a Google Play Console account (one-off fee). Both should be in your business's name, not the agency's. If your developer offers to publish under their account, decline: the listing, reviews and ratings belong to whoever owns the account, and moving an app between accounts later is painful. We build under our clients' accounts as standard - it is on our app development page for that reason.

Legal pages

A privacy policy at a public URL, specific to the app, is mandatory for both stores. Terms of use if the app has accounts or purchases. A support URL or email that actually gets answered.

Store assets

App name (check it is available), subtitle, description, keywords (Apple), category, age rating questionnaire, screenshots for every required device size, and an icon that meets each store's specification. Screenshots must show the real app, not mock-ups.

What apps actually get rejected for

Privacy and data

The most common rejection in recent years. Apple's privacy nutrition labels and Google's data safety form must accurately describe what the app collects and why. Asking for a permission (location, camera, contacts) without a clear in-app reason, or before the user needs it, is a rejection. Tracking users across apps without asking is a rejection on iOS.

Accounts

If your app offers third-party sign-in (Google, Facebook), Apple requires Sign in with Apple too. If users can create an account in the app, they must be able to delete it in the app. Reviewers need a working test account - provide one with real-looking data.

Incomplete or broken

Placeholder text, dead links, crashes on launch, features that need a backend which is not running during review. Reviewers test on real devices; if a screen depends on data that does not exist yet, it will be found.

Payments

Digital goods and subscriptions inside the app must use the store's in-app purchase system (with its commission). Physical goods and services delivered outside the app may use your own payment provider. Getting this wrong is an immediate rejection and a common one for booking and membership apps.

Minimum functionality

Apple rejects apps that are "just a website in a wrapper" or that do too little. If the app does not do anything a web page could not, this is a risk - and a sign you should have built a web app, as we discuss in our native versus cross-platform guide.

The checklist

1. Developer accounts in the business's name, with a D-U-N-S number for Apple.
2. Privacy policy and terms at public URLs, matching what the app really does.
3. Privacy labels and data safety form completed and accurate.
4. Every permission requested in context, with a plain-English reason string.
5. Sign in with Apple offered if any third-party sign-in is.
6. In-app account deletion if in-app account creation exists.
7. Correct payment route for what is sold.
8. No placeholder content, all links live, backend running and stable.
9. Test account credentials and reviewer notes explaining anything non-obvious.
10. Screenshots, icon, description and age rating complete for both stores.
11. Tested on the oldest OS version you claim to support.

Planning for review time

Apple typically reviews within 24 to 48 hours now, but plan for a week and one rejection cycle. Google is usually faster for updates and slower for a brand-new developer account, where extra identity verification can add days. Do not announce a launch date until the app is approved. We build two to three weeks of store time into every plan - it is in our homepage FAQs because clients ask every time - and treat approval, not submission, as the milestone.

Company accounts: the details that delay UK businesses

Apple requires organisations to enrol as a company, not an individual, and verifies this against a D-U-N-S number - a free identifier from Dun and Bradstreet that can take one to two weeks to issue if your company does not already have one. Apply before the app is finished, not after. The person enrolling must have legal authority to bind the company, and Apple may phone to check. Google's organisation verification asks for company registration details and a matching website. Both processes have delayed launches by weeks when started late.

What reviewers actually do

A human installs your app on a device, opens it, tries the main flows with the test account you supplied, checks every permission prompt, looks at every screen for placeholder content, and compares what the app does with what your privacy declarations say. Anything that needs an external condition - a live backend, a specific location, a physical device - must either work during review or be explained in the reviewer notes with a way to test it. Reviewer notes are the most underused tool in the process: a short paragraph explaining what the app is for and how to reach each feature prevents most misunderstandings.

After approval

Releases can be phased (a percentage of users at a time) on both stores, which limits the damage from a bug that only appears at scale. Crash reporting should be in from day one. Reviews and ratings need replies. And the app is not finished: within twelve months a store rule will change and a release will be needed just to remain compliant - one of the year-two costs in our app cost guide.

Common UK-specific snags

• Privacy policies that cite GDPR generically but do not describe what the app itself collects.
• Age ratings answered casually; a questionnaire mistake can rate a business app as adult content.
• Card payments for services (allowed via your provider) mixed with digital content (must use in-app purchase) in one flow.
• Screenshots showing a different brand or an old design.

Handling a rejection

Read the rejection message carefully; reviewers cite the specific guideline. Most rejections are fixable in a day: an added explanation string, a corrected privacy label, a missing deletion flow. Reply in Resolution Center with what you changed and why, resubmit, and expect a faster second review. If you believe the reviewer is wrong, appeal with specifics - it works more often than people expect - but do not argue about policy. If the rejection is for minimum functionality, the answer is usually to reconsider whether the product should be a native app at all, and our native versus cross-platform guide covers the web app alternative.

If you want the submission handled as part of the build, under your accounts, tell us about the app.