Getting your app through App Store review the first time

A rejection from App Store review does not cost much money, but it costs days — and it tends to arrive the week you promised a launch. Almost every rejection we have seen falls into a handful of categories that can be checked before you submit. This is the list we go through.

Before you build: the account

• The developer account should be yours, in your company’s name, not ours. It takes Apple a few days to verify a company, longer if the legal entity details do not match the D-U-N-S record, so start it the week the project starts, not the week before launch. Same for Google Play.
• Set up App Store Connect users for the people who will need access, with the right roles.
• Decide who owns the app’s bundle identifier and signing — again, you.

Things that get apps rejected

• A reviewer cannot log in. If the app needs an account, provide a working demo login in the review notes, and make sure it works on a fresh install. A surprising number of rejections are simply “we could not get past the sign-in screen”.
• Features that need something the reviewer does not have. A real badge to scan, a specific location, a hardware device. Provide a demo mode, or a video, and explain it in the notes.
• Permissions without explanation. Every camera, location, contacts or photo permission needs a purpose string that says why, in plain language. “This app needs access to your location” is not a reason.
• Account deletion. If users can create an account, they must be able to delete it from inside the app. This is checked.
• Payments. Digital goods and subscriptions must use in-app purchase; physical goods and real-world services must not. Getting this wrong is a guaranteed rejection, and the rule is strict.
• Sign in with Apple. If you offer Google or Facebook login, you must offer Apple’s too.
• Placeholder content. Lorem ipsum, “coming soon” screens, broken links in the privacy policy. Reviewers notice.
• Privacy labels and tracking. The App Privacy section must match what the app actually does, and any tracking needs the tracking-permission prompt.
• Crashes on launch on a device or OS version you did not test. We test on the oldest version you support, not just the newest.

Google Play has its own list

Play is more automated and generally faster, but has its own habits: a data-safety form that must be accurate, a target API level that must be recent, a published privacy policy URL, and — for new personal accounts — a closed test with a minimum number of testers before production is allowed. Business accounts avoid that last one, which is another reason to set the account up early and correctly.

The release itself

We submit to both stores at the same time, with a phased or staged rollout so a problem on day one reaches a fraction of users rather than all of them. The first version goes out with a kill-switch for anything that talks to a backend we might need to change, and with crash reporting in place so we hear about problems before you do.

Timing

Plan for review to take a few days, and for one round of back-and-forth to be normal even when you do everything right. If you need the app live for a specific date — a trade show, a launch event — the first submission should go in at least two weeks before it. Everyone who has done this once agrees; everyone doing it for the first time thinks it is pessimistic until it isn’t.