Why Apps Get Rejected From the App Store and Google Play

Indore, 1 November 2026, I get asked a version of the same question near the end of almost every app project: what happens if Apple says no? Founders have usually heard a story from a friend whose app sat in review for a week and came back with a rejection they did not understand.

It is rarely a mystery. App Store review and Google Play review both follow published rules, and the reasons apps get sent back repeat a lot. Store submission is the last step of every project we run, so this is the list I go through before a build goes to either store. Most of it is tedious. That is exactly why it gets skipped.

The app breaks or looks unfinished

Crashes on a clean install

This is the most ordinary reason and the most avoidable. A reviewer installs your build on a real device, opens it and starts tapping. If it crashes on launch, hangs on a loading spinner or throws an error on the first screen that needs the backend, the review ends there.

The trap is that the app works perfectly on the developer's phone, with a warm cache, an existing account and a fast connection. The reviewer is a brand new user on a clean install, often far from your servers.

So the build we submit has to survive a cold start. Our sprints already send test builds out through TestFlight on iOS and Google Play internal testing on Android, and we run structured QA on each milestone with edge cases written down and fixed. On Keen as Mustard, the dating app we built for two founders in Sydney, 546 internal testers used those test builds before the client tested on their own devices. That app was delivered but never went to the public stores, because the founders paused the launch for personal reasons, so I am not going to claim it sailed through review. But a wide test group finds the same problems a reviewer would: the odd device, the slow network, the sign-up step that breaks if you go back a screen.

My one rule here: the last check before upload should be done by someone who did not build the feature. Fresh install, new account, every main flow. Developers test the path they wrote. Reviewers do not.

Placeholder content and dead links

Reviewers notice lorem ipsum. They notice a button labelled "Coming soon", a settings screen with nothing in it, a support link that goes to a 404 and a privacy policy URL that points at a template. Each of these reads as an unfinished app, and both stores treat unfinished apps as a reason to reject.

This usually happens because content arrives late, someone drops in a placeholder to keep moving, and nobody removes it. The fix is boring. List every link and every piece of copy that came from outside the codebase, and check each one by hand before upload:

• Privacy policy and terms URLs open real, current pages on the client's own domain.
• Support and contact links work and reach a person.
• No test data, dummy restaurants or sample profiles are visible to a new user.
• Every button visible in the release build does something.

If a feature is not ready, my advice is to hide it completely rather than show it disabled. A missing feature is fine. A broken one isn't.

No working demo account for the reviewer

If your app needs a login, the reviewer needs one too. Both stores give you a place in the submission form to add sign-in details and notes for review. Leaving it empty, or giving a login that has expired, is one of the most common reasons an app comes back with a polite request for more information.

It gets trickier when sign-up is gated. Keen as Mustard has dual verification: a live selfie scan plus a government ID match before a user gets the verified badge. A reviewer cannot be expected to upload their own ID to test your app. For an app like that, the answer is a demo account that is already verified, with enough data around it (matches, chats, a subscription state) that the reviewer can see every feature without hitting a wall. The same goes for invite codes and anything that waits on an admin approval.

Write the review notes as if the reviewer has never heard of the product, because they haven't. A few plain sentences on what the app does and how to log in is enough.

Privacy disclosures that do not match what the app does

Both stores now ask you to declare what data your app collects and why. On iOS that is the privacy details section on the App Store listing. On Google Play it is the Data safety form. Separately, every permission the app requests on iOS (location, camera, contacts, photos) needs a short message explaining why the app wants it, shown to the user at the moment it asks.

Rejections here come from mismatch. The form says the app collects no location data, but the app asks for location. Or a third-party SDK collects things the founder did not know about. Or the permission message just says "This app needs your location", which tells the user nothing.

Our apps lean on permissions more than people expect. Lalah, a halal food discovery app we built for a founder in Melbourne, uses location for the map view and for location-based prayer times. Keen as Mustard reads the phone's contacts for its contact blocking feature, which hides you from people in your contacts and them from you. Both of those need a clear, honest reason in the permission prompt and a matching line in the privacy declarations. Fill in those forms from the actual list of SDKs and permissions in the build, not from memory. The privacy policy on the website has to say the same thing.

Account deletion, payments and the rules founders miss

Three rules catch first-time founders.

The first is account deletion. If your app lets people create an account, Apple expects them to be able to start deleting that account from inside the app, not by emailing support. Google Play also asks for a way to request deletion, including a web link that works without the app installed. That needs a real backend process behind the button, so it belongs in the user stories, not in a launch-week scramble.

The second is payments for digital goods. If you sell something used inside the app, like a premium subscription, extra features or in-app currency, both stores generally require you to use their own billing. Physical goods and real-world services are different and can use your own payment provider. Keen as Mustard's premium subscriptions run through RevenueCat, which sits on top of Apple and Google billing, so the app follows those rules by design. Where founders get caught is a "subscribe on our website" link inside the app, or a premium plan sold through a card form. Rules here have been changing in some regions, so check current guidance for your market at submission time.

The third is user-generated content. If people can post things other users see, the stores expect moderation, a way to report content and a way to block users. Lalah's community restaurant submissions are reviewed by an admin before they are published, and Keen as Mustard's admin panel covers moderation. That answers the reviewer's question before they ask it.

Apps that do not do enough

This one is harder to put on a checklist. Apple in particular rejects apps that feel like a website wrapped in an app shell, or that offer very little a user could not get elsewhere.

I think this is the only rejection reason that is really a product question. If the app is a thin layer over a web page, no submission note will save it. It needs to become a better app, with native navigation, features that use the phone properly, content that is useful offline or on the move. We talk about this at the user story stage, long before the store is involved, because by submission time it is too late to change. If you are still deciding what your first version should include, our mobile app development page explains how we scope it.

When the review comes back anyway

One small thing I would add: take the store listing screenshots from the current build, not from the Figma file. Designs drift during development, and a screenshot that shows a screen the app no longer has is an easy thing for a reviewer to flag.

Even with all of this done, a reviewer can still come back with a question. That is normal, and it is not a verdict on the product. Reply in the review thread, fix what they ask for and resubmit. I tell founders to leave a little room between the planned submission date and any launch announcement.

Where this fits in the wider project is covered in our app development process guide. If you have a build that keeps coming back from review, or you want a second pair of eyes before your first submission, get in touch.