App Store and Google Play review: what actually gets an app rejected

Store review has a reputation for being arbitrary, and almost all of that reputation comes from the first submission of a team that has not done one before. In practice the reasons an app is rejected are few, documented and repeated. They are rarely about the product itself. They are about the reviewer being unable to see it, the paperwork disagreeing with the code, or money moving through the wrong channel. Each of them can be prepared for before the build is uploaded, and every one of them costs days when it is not.

Start with access, because it is the most common and the most avoidable. If any part of the app sits behind a login, both Apple and Google expect working credentials with the submission: Apple in the App Review Information, Google in the App access declaration in the Play Console. The account has to work on the day the reviewer opens it, which is not necessarily the day you submitted. A demo account that has been deleted, locked, expired or emptied by a cleanup job is a rejection, and it is one that keeps happening on later versions too, because every update is reviewed again. Treat the review account as part of the production system: owned, documented, excluded from cleanups, and checked before each submission.

The same goes for anything the reviewer needs in order to reach the interesting part. A sign-in by one-time code needs a way for the reviewer to receive the code. A booking flow needs something bookable. A feature limited to Greece needs a note explaining it to a reviewer who may not be in Greece and may not read Greek. The notes field exists for exactly this, and a short, plain paragraph there prevents more rejections than any amount of polish.

Then completeness. Apple will refuse an app that crashes, shows placeholder content, links to pages that do not exist or describes features in its listing that the build does not contain. Screenshots must show the app as it is. And an app that is little more than a website in a frame is refused under the minimum functionality guideline — the same conclusion this journal reaches for commercial reasons, arrived at by a reviewer with a checklist.

Privacy is where the paperwork and the code must agree. Apple asks for privacy labels describing what the app collects and why, and requires a privacy manifest for certain system APIs; Google asks for the Data safety section in the Play Console. Both are declarations made by you, and both are judged against what the app actually does — including what every third-party SDK inside it does on your behalf. An analytics library, a crash reporter or an advertising SDK added late in the project changes the honest answer. The practical rule is to keep a list of every SDK and what it collects, and to update the declarations whenever that list changes rather than when a reviewer points it out.

Account deletion is now a requirement on both platforms, and it is more specific than many teams assume. If people can create an account in the app, Apple expects them to be able to start deleting it from inside the app, not only by emailing support. Google Play additionally asks for a web address where deletion can be requested without reinstalling the app, declared in the Data safety section. Deleting an account means deleting or anonymising the data behind it, within the rules the business already has to follow for invoices and bookings. It is a back-end feature as much as a screen, and it belongs in the first version.

Sign-in has its own rule on iOS. An app that offers third-party sign-in, such as Google, must also offer an equivalent option that limits data collection and lets people keep their email private, and Sign in with Apple is the usual way to meet it. Adding it after a rejection is a few days of work across the app and the API; planning it from the start is an afternoon.

Payments are the rule most often misunderstood. Digital goods and services used inside the app — subscriptions, premium features, in-app currency — must be sold through the stores' own billing on iOS and generally on Google Play too, with the stores' commission. Physical goods and services consumed outside the app are a different category: a retail order, a hotel stay or a table booking is paid through an ordinary payment provider, and trying to route it through in-app purchase is itself a mistake. Know which side of that line every product in the app is on before the payment screens are designed.

Wallets add a step of their own. Apple Pay needs a merchant identity configured with Apple and the payment provider. Google Pay in an Android app works in a test environment during development, but taking real payments requires the business to request production access in the Google Pay and Wallet Console and have the integration approved — a separate process from Play review, on its own timetable. An app can pass review, go live and still fail at the Google Pay button because that approval was never requested.

New Google Play developer accounts face one more gate. Personal developer accounts created since late 2023 must run a closed test with a minimum number of testers for a fixed period before they can apply for production access. Organisation accounts, verified as a business, are not subject to that rule, which is one more reason to open the developer account in the company's name from the start.

None of this is difficult, and all of it is easier as a checklist than as a lesson. Before every submission: the review account logs in, the notes explain anything a stranger would not understand, the privacy declarations match the current SDK list, deletion works end to end, payments sit on the right side of the line, and wallet approvals are in place. We work through that list for every release of the apps we build and maintain, including TRVL AIR on the App Store and Google Play, and the reward is dull: reviews that pass, on the first attempt, without a story to tell.