The most common app store rejections

Apple's

1. A test account that does not work. The reviewer has to get in. If the app has login and you did not leave a valid username and password in the review notes, rejection is certain. Check that access on submission day, not the week before.

2. Privacy that does not match. What the app collects has to be what the listing says it collects, and the privacy policy must live at an address that opens.

3. No way to delete the account. If the app lets people create an account, it has to let them delete it, from inside the app. One of the easiest to avoid and most common to receive.

4. "This is a wrapped website." An app that is just your site in a frame, with nothing to justify being in the store, gets rejected. If your case is content and a form, the honest path is usually to publish on the web.

5. Payments outside the store. Digital content consumed inside the app has to go through store purchase. Physical goods and services delivered outside do not. Confusing the two means rejection and sometimes removal.

6. User content with no brakes. If people write, post or talk, the app needs filtering, reporting, blocking and a contact. Without all four, it does not pass.

Google's

1. A wrong Data safety form. The champion. What you declare has to match what the app does, including what third-party libraries send out.

2. Permissions with no justification. Location, camera, contacts: every requested permission needs a visible feature that uses it. A spare permission is a rejection.

3. An old target API level. The requirement rises every year. An app below the minimum is neither published nor updated.

4. Closed testing not completed. New personal developer accounts need the testing period with testers before publishing. It is not a content rejection, it is a prerequisite, and it holds the launch.

5. Missing privacy policy. A public address that opens, with the actual text.

What to do before submitting

• log in with the test account you wrote in the notes, on submission day;
• open the privacy policy in a private window;
• go permission by permission: does each one have a screen that uses it?
• confirm the data form says what the app does;
• if there are accounts, find the delete-account button;
• if there is user content, find the report button.

Six checks, fifteen minutes, and they cover most of the rejections on this list.

The summary

• rejection is common and almost always paperwork, not code;
• on Apple: test account, privacy, account deletion, "wrapped website", payments and user content;
• on Google: data form, spare permissions, target API level and closed testing;
• the cost of a rejection is calendar time, which is why checking first pays;
• if the app is content and a form, it may not need the store at all.