Getting your app approved on Google Play.
Same idea, different rulebook.

Forms first, then a person.

Play checks your declarations before anyone opens the app: the data safety form, the content rating questionnaire, the permissions you request, the target audience, and whether your account has met its testing requirement. Then a reviewer or an automated pass opens the build. Apps are returned for policy problems, removed later for the same, and suspended for repeat offenses. Why: Play operates at a scale where the declarations are the first line of defense, and a wrong declaration is treated as a broken promise.

Billing, deletion, and data.

1. Google Play Billing.

   Digital goods and services used inside the app go through Play's billing system. Physical goods and services consumed outside the app do not. Why: same logic as Apple; the platform's commerce runs through the platform.

2. Account deletion, in the app and on the web.

   If people create accounts, Play requires a way to delete the account inside the app and a web link to request deletion that you declare in the console. Why: a person should be able to remove their data whether or not they still have the app installed.

3. The data safety form.

   You declare what you collect, what you share, and why, and the form has to match what the app actually does. Why: the form is shown to users before install; a mismatch is a false statement to them.

4. Permissions.

   Every sensitive permission needs a reason the reviewer accepts, and some need a declaration form. Why: location, contacts, SMS, and file access are where abuse lives.

It has to work, and Play wants proof you tested it.

1. Closed testing before production.

   New personal developer accounts have to run a closed test with real testers for a period before production access. Why: Play wants evidence the app has been used by people who are not you.

2. Login credentials for review.

   If the app needs an account, valid credentials go in the console's app access section. Why: the reviewer cannot approve what they cannot open.

3. Broken functionality.

   Crashes, dead buttons, coming soon screens, and features that do not do what the listing says are returned. Why: the store lists finished products.

4. Target API level.

   Play requires apps to target a recent Android version. Old targets are blocked from publishing. Why: newer targets carry the security and privacy behavior users are promised.

5. Screenshots and listing.

   Screenshots must show the app as it is, and the listing cannot claim features that do not exist or hide that a feature is paid. Why: the listing is the promise.

If people can post, you are responsible for what they post.

1. User-generated content.

   Apps with posts, messages, or profiles need reporting, blocking, moderation, and a way to reach you. Why: Play holds the developer responsible for the space they created.

2. Content rating and target audience.

   The questionnaire decides who sees your app. Answer it for the app you shipped, not the one you plan. Why: a wrong rating puts the app in front of the wrong people.

3. Families and ads.

   If children could be an audience, a separate set of rules applies to ads, data, and content. Why: the strictest rules protect the youngest users.

The Android checklist, at a glance.

• Digital goods go through Play Billing.
• Account deletion works in the app and there is a web request link declared in the console.
• The data safety form matches what the app actually collects and shares.
• Every sensitive permission has a reason the app visibly needs.
• The closed test has run with real testers if your account requires it.
• Review credentials are in the console and work today.
• Nothing crashes, nothing says coming soon, every link resolves.
• Target API level is current. Screenshots are from this build.

The Pro pack is the full checklist with the policy each item comes from, the console walkthrough of every form, and response templates. The App Review Auditor agent checks your project and your declarations against it and fixes what you approve.

Describe it honestly.

The four things Play will ask you first. Entries stay on this page and are not sent anywhere.

A readiness read for Play.

Paste a plain description. It tells you which policies apply, where you are likely to be returned, and the declarations to get right before you touch the console.

I am preparing an Android app for Google Play review. From my description, tell me which of these areas apply and, for each that applies, whether I am likely to pass or be returned, and the one thing to get right before submitting. Do not tell me how to build anything. Explain what the policy is and why Play has it.

Areas: Play Billing for digital goods, account deletion in the app and on the web, the data safety form, sensitive permissions and their declarations, closed testing before production, review credentials, broken functionality and placeholder screens, target API level, screenshots and listing accuracy including paid features, user-generated content controls, content rating and target audience, families and ads.

End with: the three areas most likely to send my app back, in order.

MY APP:
[what it does, how people pay, what data it collects, permissions, whether there are accounts, what users can post, who the audience is, whether real testers have used it]

One prompt. Paste it into Claude. It builds the whole thing for your business.

The Pro pack is a build prompt with blanks for your context: your product, your medium, your team. Fill them in, answer its questions, and it produces the complete system in your words. The PDF explains the method so you can judge the output. The reviewer's forty-item checklist with the policy behind each item, the console walkthrough of every form, the account deletion requirement done right, the permissions and data safety rules, and the response templates.