What Actually Gets Apps Rejected From the Stores

Rejection is a normal part of shipping, and the avoidable half of it clusters in a handful of places that both stores document publicly. This guide quotes those documents directly, because being able to point at the exact sentence is what turns an argument with a reviewer into a fix.

It also covers the part almost nobody writes about: the two stores punish repeat offences very differently, and only one of them can take your account.

Key Takeaways

• Apple requires final builds: "placeholder text, empty websites, and other temporary content should be scrubbed before submission" (Apple).
• If your app has a login, Apple expects demo credentials and a live backend.
• A repackaged website usually fails guideline 4.2.
• On Google Play, enforcement escalates: rejection → removal → suspension → limited visibility → account termination (Google Play).
• You are responsible for what third-party SDKs in your app do.

The guidelines Apple actually cites

Four of them account for a large share of avoidable rejections. The wording matters, so these are quoted rather than paraphrased.

2.1 — App Completeness

"Submissions to App Review, including apps you make available for pre-order, should be final versions with all necessary metadata and fully functional URLs included; placeholder text, empty websites, and other temporary content should be scrubbed before submission."

And, specifically:

"Make sure your app has been tested on-device for bugs and stability before you submit it, and include demo account info (and turn on your back-end service!) if your app includes a login."

Read that parenthesis again — "and turn on your back-end service". It is in the guidelines because it happens often enough to warrant an exclamation mark. A staging backend that is asleep when the reviewer opens the app produces a rejection that has nothing to do with your app.

The other frequent version of this: a support URL or privacy policy URL that points at a page which does not exist yet. It is metadata, it feels administrative, and it fails the submission.

4.2 — Minimum Functionality

"Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or 'app-like,' it doesn't belong on the App Store."

This is the guideline behind most "why was our app rejected, it works fine" conversations. The app working is not the test. If your product is a website and the app is a container for it, this is a design problem to solve before submission, not an appeal to file after.

If you are still deciding whether you need an app at all, that question is worth answering honestly first — what an app actually costs covers the commitment you are taking on.

5.1.1 — Data Collection and Storage

"All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner."

Note the "and within the app". A privacy policy that exists only in the store listing does not satisfy this — and the policy is the easy half, next to declaring what every SDK sends off the device. And:

"Apps that collect user or usage data must secure user consent for the collection, even if such data is considered to be anonymous at the time of or immediately following collection."

Anonymous does not exempt you from consent.

3.1.1 — In-App Purchase

"If you want to unlock features or functionality within your app … you must use in-app purchase. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc."

If your business model routes payment around the store for digital content, that is a commercial decision to take deliberately and early, not something to discover at submission.

And one that catches teams planning a soft launch

"Demos, betas, and trial versions of your app don't belong on the App Store – use TestFlight instead."

Google Play punishes repetition, not just the submission

The two stores treat a repeat offender differently, and that asymmetry should change how you treat a rejection.

An App Store rejection is a message: fix it, resubmit, move on. Google Play's enforcement documentation describes something else — a ladder:

1. Rejection — the app or update is not published
2. Removal — the app is taken off the store
3. Suspension — the app is removed and it counts as strikes against account standing
4. Limited visibility — the app stays up but is harder to find
5. Account termination — all apps removed permanently

And the sentence that should make anyone with more than one app pay attention:

"Repeated or serious violations (such as malware, fraud, and apps that may cause user or device harm)…will result in termination of individual or related Google Play Developer accounts."

Related accounts. A problem in one product can reach the others.

The other line worth internalising:

"you are responsible for ensuring that any third-party code (for example, an SDK) used in your app, and such third party's practices with respect to your app, are compliant with all Google Play Developer Program policies"

An advertising or analytics SDK that collects more than your data-safety declaration says is your violation. You did not write it, you did not choose its behaviour, and it is still yours. This is a real argument for keeping the dependency list short.

Rejection is not the only store-side wait: Google Play's 14-day closed test for new personal accounts and the account verification times are covered in how long does it take to build an app.

A pre-submission pass that costs an hour

Derived from the guidelines above rather than from folklore.

Is every URL in the metadata live? Support, marketing, privacy. Open each one in a private window.

Is the privacy policy reachable inside the app, not only in the store listing?

Is there a working demo account, and is the backend it talks to actually running? Not staging-that-sleeps. Running.

Would a stranger call this app-like? If the honest answer is "it is our website with a bottom bar", solve that first.

Does anything unlock without in-app purchase? Licence keys, codes, external payment for digital content.

Does your data-safety declaration match what your SDKs actually collect? This one requires checking the SDK, not the declaration.

Have you tested on a real device, not only a simulator? Apple names this explicitly.

Have you left buffer in the launch date? Review time is not yours to control. The mobile app development guide covers realistic timelines including the review window.

In short

Most avoidable rejections are the same handful of things: an unfinished build, a dead URL, a login the reviewer cannot get past, a privacy policy that only exists in the listing, or an app that is a website in a shell. All of them are documented by the stores in plain language, and all of them are cheaper to fix before submission than to argue about after.

And on Google Play, treat rejection as a warning rather than a retry. The ladder ends somewhere you do not want to be.

If you would rather have someone who has taken apps through both processes look at yours before you submit, that is a short conversation.