The Final Review: A Checklist to Run Before Every App Submission

Most app submission issues are discovered by reviewers, not by developers, because developers test the happy path while reviewers test the edges. Running a deliberate final review before every submission catches the problems that produce rejection emails and suspension warnings. Here is the checklist we run on every app before it reaches a reviewer.

Functional Integrity

Reviewers open your app on a real device, often a low-end one, on wifi and on a slow network. Test the same way:

• Install from a clean state on a real device — no developer builds, no shortcuts.
• Force-stop and restart the app several times; confirm no crash loops.
• Toggle airplane mode and confirm graceful offline behavior.
• Rotate the device and resize windows; confirm layouts do not break.
• Use the app without logging in. Anonymous and signed-out paths must be fully functional.

The single most common rejection trigger we see is a crash on the anonymous path. Users and reviewers both try the app before signing in, and if it dies there, nothing else matters.

Permissions: Ask Only What You Use

List every permission in your manifest and justify each one. Reviewers compare declared permissions against actual app behavior. Location permission in a shopping list app, or microphone permission in a tip calculator, are the kind of mismatch that generates an instant warning.

Request permissions at the moment of use with a clear explanation, never all at install time. Apps that declare sensitive permissions but never use them responsibly are the ones flagged for deceptive behavior.

Store Listing Accuracy

Everything in your listing must match what the app actually does.

• Title and description state real functionality — no over-promising.
• Feature graphic and screenshots show the current UI, not old designs.
• Category matches the app.
• Content rating questionnaire matches your content.
• Privacy policy link works and matches data practices.
• Ads SDKs are declared in the Data Safety form.

Re-read your description as a stranger. If a phrase sounds like a claim your app cannot prove, remove it before the reviewer reads it.

Payment and Content Compliance

If your app sells digital goods or unlocks digital features, those purchases must go through Google's billing system per Play policy — workarounds are a direct path to removal. Physical goods, like a delivered product, can use other payment processors. Know which side of that line your app sits on and design accordingly.

User-generated content needs reporting and blocking tools. Apps with chat, comments, or uploads must give users a way to flag content and block others. Prepare these before submission, not after a reviewer flags their absence.

Final Pre-Submission Hour

When everything looks clean, do a fixed checklist pass:

• Build a fresh signed release bundle.
• Install the actual bundle — not a debug build — on a clean device.
• Walk the entire core user journey twice.
• Confirm the Data Safety form matches the SDKs in the final build.
• Confirm the privacy policy URL is live from an external network.
• Fill helpful release notes.

This last hour is the cheapest insurance in publishing. Ten minutes of extra checking on your side can save weeks of review back-and-forth, and for apps already live, it is the difference between an update that sails through and one that stalls the whole product.

Key Takeaways

• Test the anonymous path before anything else — it is the single most common rejection trigger we see.
• Justify every permission in the manifest; declaring permissions you never use reads as deceptive behavior.
• Make the store listing match the app exactly: text, screenshots, permissions and offline behavior reviewed by a human.

Frequently Asked Questions