App Store and Google Play: the 9 rejection reasons we see most

The most frustrating part of a mobile project is not development: it is the week when the app is finished but not published. A rejection costs three to seven days, and it almost always lands in the week when the communication has already gone out.

Here are the nine reasons we come across most, and how to eliminate them before you submit.

1. Privacy and data collection declaration

This has become the leading cause of rejection on both platforms. The stores check consistency between what you declare you collect, what your app actually collects — third-party libraries included — and what your privacy policy states.

What is checked: the privacy label on the store listing, the existence of a publicly accessible privacy policy, and the presence of a way to delete one's account from within the app when the app lets people create one.

The pitfall: an analytics tool or ad network integrated by a developer collects identifiers that nobody thought to declare. The subject directly overlaps with GDPR compliance.

2. No working test account

The reviewer must be able to use the whole app. If they hit a login screen with no credentials, they reject it — it is automatic and perfectly avoidable.

Provide a demo account with realistic data, valid for at least a month, and if the app requires a one-time code, explain how to bypass it or provide a test number.

3. Incomplete feature or placeholder content

An empty screen, an inactive button, a "coming soon" feature, forgotten placeholder text, a link that goes nowhere. An app still being finished is rejected, even if the main part works.

4. Payment bypassing the platform's system

On iOS, any purchase of content or a service consumed in the app must go through the in-app payment. Redirecting the user to a web payment for a digital subscription is a classic reason for rejection — and the exceptions are narrower than most teams believe.

Physical goods and services, on the other hand, are normally paid for by an external method. The boundary is sometimes subtle: to be validated up front, not the day before launch.

5. Permissions requested without justification

An app that asks for access to contacts, background location or the microphone without the use being obvious is rejected. Every permission must have a clear explanatory text, in the users' language, and be requested at the moment the user understands its usefulness — not at first launch, in a burst.

6. Non-compliant store listing

Screenshots that no longer match the app, a mention of a competing platform, a promised feature that is absent, keywords stuffed into the title, a misleading icon. The listing is examined as seriously as the app.

7. Social login without an alternative

On iOS, if you offer sign-in through a third-party service, you must offer a privacy-respecting sign-in option. It is a frequent reason for rejection and easy to fix, but it requires development — so it must be anticipated.

8. Crashes and bugs on real devices

Testing is done on physical hardware, sometimes a generation older than your developers', in degraded network conditions. The most frequent causes: a crash at first launch with no connection, a screen that freezes after returning from the background, an interface that is unreadable on a small screen or with large font sizes.

9. User-generated content without moderation

If your app lets people publish content, it must offer a way to report inappropriate content, to block a user, and terms of use. The absence of these three elements is a certain rejection.

The pre-submission checklist

To go through the day before, in an hour.

• [ ] Valid test account, with realistic data, provided in the review notes
• [ ] Privacy policy online, up to date, accessible without an account
• [ ] Data collection declaration consistent with the libraries actually embedded
• [ ] Account deletion possible from within the app, if accounts can be created
• [ ] No "coming soon" mention, no empty screen, no placeholder text
• [ ] Justification texts present for each permission, in the users' language
• [ ] Screenshots matching the submitted version
• [ ] Full test on an older device, in airplane mode, then reconnection
• [ ] Reporting and blocking available if user content is published
• [ ] Review notes explaining any non-obvious features

A rejection is not a judgement on the quality of your product. It is a compliance check. It is prepared for like a compliance check: with a list, not with hope.

What to do if you are rejected

Read the exact reason and the rule cited: the wording is standardised, the rule is numbered, and it describes precisely what the problem is.

Fix only that point, then reply in the review messaging explaining what was changed and where to verify it. A silent resubmission goes back to the bottom of the queue; a reasoned reply is often handled within a few hours.

If the rejection seems to rest on a misunderstanding — which is common when a business feature is poorly understood — the appeal procedure exists and works, provided you stay factual and cite the rule concerned.

Sources

• App Review Guidelines — Apple
• 5.1.1(v) — Apple
• Fournir les informations pour la section Sécurité des données — Google Play Console
• Contenu généré par l'utilisateur — Google Play Console