An app is not live when the developers finish it. It is live when Apple and Google have reviewed it and let it through. Both stores publish their rules, and most rejections come from the same handful of causes.
What review is
Both stores check every new app and every update before the public can download it. Part of the check is automated and part is done by a person. They look at whether the app works, whether it does what the listing says, and how it handles personal data, payments and content.
A rejection is a list of things to fix. You correct them and submit again.
The common reasons for rejection
- The app crashes or shows an obvious bug during review.
- The reviewer cannot get in, because no test account was provided.
- The privacy policy is missing, or the data declarations do not match what the app collects.
- The app asks for a permission, such as location or the camera, without saying why.
- Digital goods are sold without using the store's own purchase system.
- People can create an account but cannot delete it.
- The screenshots or description do not match the app.
- The app is a website in a wrapper, with little that an app adds.
What to prepare before you submit
- Developer accounts in the company's name. Enrolling as an organisation involves checks on the business, so start early.
- The listing: name, description, icon, and screenshots in the sizes each store asks for.
- A privacy policy at a public address.
- Answers to the stores' questions about what data the app collects and why.
- A working test account, with notes telling the reviewer how to reach each feature.
- The age rating questionnaire.
- A support address that someone reads.
None of this depends on the code being finished. It can be prepared while the app is still being built, and it usually should be.
Payments: the rule that surprises people
Digital content and features used inside the app, such as subscriptions or premium features, generally have to be sold through the store's own purchase system, and the store takes a commission. Physical goods and services delivered outside the app, such as a taxi ride or a grocery order, use an ordinary payment provider.
These rules have been changing in some regions. Check the current policy for the countries you sell in before the payment flow is designed.
Planning the launch date
Review often takes a day or two. It can take longer, and each rejection adds another round. A first submission is the one most likely to come back.
- Submit well ahead of any date you have announced.
- Ask for approval first and release manually, so the public date is yours to choose.
- Use the stores' testing channels to put the app in front of real users before the public release.
- Expect extra steps on a new developer account. Google asks some new accounts to run a closed test before they can publish.
Updates are reviewed too
Every update goes through the same process, which matters when a fix is urgent. Content that comes from your server, and features that can be switched on or off remotely, can change without a new release.
Deciding which parts of the app are controlled from the server is a design choice worth making early.
Our service
Mobile App Development
