Getting Your App Through App Store and Play Review

It helps to picture it accurately. Automated checks run first, looking at what your app declares, what libraries it contains and what it does when it starts. Then, on Apple's side particularly, a person installs your app on a real device, opens it, and works through a checklist with limited time and no knowledge of your business.

The two stores behave differently. Apple's review is more human and stricter at the gate, and a rejection there is usually a conversation. Google's is more automated at submission, with policy sweeps that can come back and remove an app months after it went live, which means a Play approval is less final than it feels.

The reviewer is not judging whether your app is good, useful or well designed. They are checking it against published rules and checking that it works. A large share of rejections are the second thing, not the first, and that share is entirely within your control.

Read the guidelines once, properly, before the first submission. They are readable, they are specific, and they are the actual test. Most teams have never read them and then treat rejections as bad luck.

The most common rejection has nothing to do with policy. The reviewer could not get in, so they could not review it, so they rejected it.

If the app needs an account, supply a demo login that works, has realistic data in it, is not rate limited, and does not expire between submission and review. Check it yourself on the morning you submit. And think about where the reviewer is sitting: if your sign in sends a one time code by text message to an Indian number, somebody reviewing in another country cannot receive it. Provide a fixed test code for that account and explain it in the review notes.

If the app needs hardware, a physical device, a bluetooth accessory or a scanner, say so and attach a video showing the app working with it. Reviewers reject what they cannot verify. A short screen recording resolves more of these than any amount of written explanation.

Then the basics that get apps rejected every day. Placeholder text still in a screen. A button that does nothing. A link pointing at your staging server. A crash on launch on whichever device they happened to pick. Test on a real device that is not the developer's, from a fresh install, with no data, on a slow connection.

Both stores require you to declare what data the app collects and what you do with it. Apple shows it as privacy labels on the listing, Google as a data safety section. Both must match what the app actually does, and both are checked against what the automated scan can see.

The trap is that the scan sees your libraries too. Your own code may collect nothing at all while an analytics or advertising library quietly collects a device identifier, and the form you filled in says otherwise. That mismatch is a rejection, and it feels unfair the first time because nobody wrote a line of code to cause it.

So do it the other way round. Get the list of every third party library in the build from your developers, read each vendor's own documentation on what they collect, and fill the form from that list rather than from memory. Apple additionally requires a privacy manifest from your app and from certain libraries, plus stated reasons for using some system functions. Your developers need to check that every library they include has kept up.

And the privacy policy link has to work. A live page, reachable without a login, that is genuinely about this app rather than a generic company page. Reviewers do open it.

If your app lets somebody create an account, it must let them delete that account from inside the app. Not by emailing support. Not through a form buried somewhere on your website. A path the user can follow themselves, in the app, that actually deletes the account and the data attached to it.

This one catches established apps on routine updates, because the requirement arrived after they were built. If your app has accounts and has not shipped since, assume this is waiting for you and build it before you need an urgent release.

Signing in has its own rules. If you offer sign in through a third party social service, Apple requires you to offer their private alternative alongside it. And you cannot demand an account for things that do not need one. An app that shows a shop's opening hours and menu behind a mandatory registration will be rejected, and rightly, because the account exists for your benefit rather than the user's.

Deletion has to be real, and you should say what happens. What is removed immediately, what is retained because the law requires it, and how long that takes. Writing that clearly on the confirmation screen answers the reviewer's question before they ask it.

Every permission needs a reason string, and the reason string is read by a person. Saying the app needs your location to improve your experience explains nothing and gets rejected. Say what the app does with it: to show you the branches nearest to you, to attach a pickup address to your order, to record where a delivery was completed.

Ask at the moment of use rather than at launch. A permission prompt on first open, before the user knows what the app is, is both a rejection risk and the single best way to have people refuse. Ask when they tap the thing that needs it, and the answer is usually yes.

Some permissions get examined much harder than others. Background location is the strictest, and you will be asked to justify it with a feature the user chose. Contacts, photos, microphone, and anything touching health or fitness data are close behind. If a feature only mildly benefits from a permission, cut the feature or find another way to do it.

The general principle is worth stating simply. Every permission you do not request is a rejection you cannot receive and a conversation you never have to have. Go through the list in your build and delete the ones nothing in the app uses any more, because those accumulate.

The rule, roughly stated: digital goods and services used inside the app generally have to be sold through the store's own purchase system, which takes a commission. Physical goods and real world services are paid for however you like, and the store takes nothing.

The grey area is wide and it is where most trouble lives. Subscriptions to a service that is also used on the web. Online courses. Bookings for something that happens in a physical place. Credits that can be spent on either digital or physical things. If your product sits anywhere near that line, get it settled before you build the payment flow, because rebuilding it after a rejection is expensive.

Linking out to your website to buy more cheaply is the classic rejection, and the rules on it have changed, are still changing, and differ by country following various legal decisions. This is the one topic in this article where you should check the current guidelines on the day you submit rather than trusting anything written earlier, including this.

Subscriptions carry their own requirements regardless. The price, the period and what happens at renewal have to be visible before the purchase, alongside links to your terms and to how the subscription is managed. Missing those is a routine and easily avoided rejection.

Screenshots must show the actual app, not a marketing illustration of a phone floating above a beach. Stuffing keywords into the app name or subtitle gets rejected. So does mentioning a competing platform in the description, describing the app as a beta or a trial, or putting a price in the text.

The age rating has to match what is actually in the app, and that includes anything users can post. If people can write, upload or message inside your app, you need a way to report content, a way to block another user, moderation that somebody actually performs, and terms that say all of this. Shipping a social feature without those is one of the fastest rejections available.

Do not describe features the build does not have. It sounds obvious. It happens constantly, because marketing writes the listing from the plan while engineering ships the subset that was finished.

Small thing, real cause of delay: your support link and your marketing link must both work and must both be about this app.

Do not resubmit unchanged and hope for a different reviewer. It occasionally works and it teaches you nothing, and repeated blind resubmissions get noticed. Read the rejection properly first, because it cites a specific guideline, and that citation tells you exactly which rule you are being measured against.

Then reply in the resolution centre rather than fixing something at random. It is a conversation with a person, and a clear, polite, factual reply with a screen recording attached resolves a surprising number of cases where the reviewer simply misunderstood what the app does. Explain the feature, say who uses it and why, and answer the specific point they raised rather than restating your case.

If a rule is genuinely being applied to something it does not cover, there is a formal appeal process and it is worth using. Use it for a real misapplication of a rule, not for a disagreement with the rule itself, which is a different conversation and one you will lose.

Finally, plan the calendar. Never submit a critical fix for the first time under a hard deadline, because the first submission of anything is the one most likely to be questioned. Build a buffer into every release plan, keep the app compliant during quiet months, and treat store review as a supplier with its own lead time rather than as a formality at the end.