Publishing Your First App on Google Play: The Complete 2026 Checklist

Writing the app is the part everyone plans for. The gap between a finished build and a live Play Store listing is the part that surprises people — and it is where first launches slip by weeks.

This is the checklist I work through, in order, drawn from taking twelve apps through the Play Console. Follow it top to bottom and nothing should ambush you.

1. Developer account

• Register at the Play Console. One-time fee of 25 USD, no annual renewal.
• Choose your account type deliberately. Personal is fast but carries the 12-tester requirement. Organisation needs a D-U-N-S number and identity verification but skips closed testing. If you have a registered business, weigh the D-U-N-S wait against the 14-day test.
• Complete identity verification. Google will ask for government ID and address confirmation. Do it immediately — it can take days and blocks everything downstream.
• Set up a payments profile if you plan to charge for the app or sell in-app products. This also takes time to verify.

2. Prepare the build

• Set a unique, permanent application ID. Something like net.yourdomain.appname. This can never be changed after publication — not renamed, not reused, not recovered if you delete the app. Get it right.
• Set versionCode and versionName. versionCode is an integer that must increase with every upload. versionName is the human-readable string.
• Target the required API level. Google raises this annually and enforces it for new submissions and updates. Check the current requirement before you build; being one level behind blocks the upload outright.
• Build a signed release .aab, not an APK. App Bundles have been mandatory for new apps since August 2021.
• Enable code shrinking and obfuscation for release builds, and keep the mapping file so crash reports stay readable.
• Test the release build on a real device. Release builds behave differently from debug builds — obfuscation breaks reflection, and network security config differs. A shocking number of crashes only appear here.

3. App signing — the step you cannot undo

This deserves its own section because getting it wrong is unrecoverable.

• Generate an upload keystore and back it up in at least two places that are not your laptop. If you lose it and are not enrolled in Play App Signing, you can never update your app again. Not "with difficulty" — never.
• Enrol in Play App Signing. Google holds the app signing key and you sign uploads with a separate upload key. If the upload key is lost, Google can reset it. This is the safety net and you should use it.
• Record the keystore password, key alias and key password in a password manager alongside the file itself.

4. Store listing assets

Produce these before you start filling in the console, or you will stall halfway through the form.

The screenshots and the short description do most of the conversion work. Almost nobody reads to 4,000 characters, but Play's search indexes it — write it for both, with the first two lines aimed squarely at humans.

5. Content declarations

This section causes more rejections than the app code ever will.

• Privacy policy. A live URL on a stable domain. Required for any app handling personal or sensitive data, and for anything targeting children. In practice: publish one.
• Data safety form. A self-declaration of what your app collects, what it shares, whether it is encrypted in transit, and whether users can request deletion. It must match reality including your third-party SDKs. An analytics or ads SDK collects data on your behalf and you are responsible for declaring it. Mismatches here are the most common rejection I see.
• Content rating questionnaire. Answer accurately. Under-rating gets the app pulled later.
• Target audience and children's policy. If your audience includes under-13s, a substantially stricter policy set applies.
• Ads declaration. Declare it if the app contains ads, including ads inside an SDK you added.
• Permissions justification. Sensitive permissions — location, camera, contacts, all-files access — need a documented reason. Remove any permission you do not genuinely need; every one is a rejection surface.
• App access instructions. If the app has a login, provide working test credentials. Reviewers who cannot get past your login screen reject the app.

6. Testing tracks

• Internal testing — up to 100 testers, available in minutes, no review. Use this constantly during development.
• Closed testing — the track that satisfies the 12-tester requirement. Start early.
• Open testing — public beta, anyone can join. Useful for gathering scale feedback before launch.
• Production — the live listing.

Ship through internal from day one. It costs nothing and means the release pipeline is already proven by the time it matters.

7. Submit

• Select countries and regions. Worldwide is the default; restrict only for a deliberate reason.
• Set pricing — free or paid. A free app can never be switched to paid. You can go paid to free, never the reverse.
• Use a staged rollout for the first production release. Start at 20%. If crash rates spike, halt before it reaches everyone.
• Submit and wait. First reviews from a new account commonly take up to seven days. Later updates are often a day or two.

8. After you are live

Publication is the start of the work, not the end.

• Watch Android vitals in the console. Crash rate and ANR rate above Google's thresholds get your app demoted in search and eventually flagged.
• Wire up Crashlytics and actually read it.
• Reply to reviews. Response rate influences perception, and a fixed one-star review is often revised upward if you tell the person you fixed it.
• Diarise the annual target SDK deadline. Google raises the requirement every year and apps that miss it stop being discoverable to new users, then get delisted.
• Iterate the listing. Change the icon, the short description, the first screenshot — one at a time — and watch the conversion rate in the console. This is the cheapest install growth available to you.

The five rejections I see most

1. Data safety form does not match app behaviour. Usually a forgotten SDK.
2. Missing or unreachable privacy policy. A dead link counts as missing.
3. Sensitive permission with no justification. Especially background location and all-files access.
4. Reviewer could not access the app. No test credentials for a login-gated app.
5. Metadata policy violation. Keyword-stuffed titles, competitor names in the description, or "#1" and "best" claims you cannot support.

All five are fixable in under an hour — but each one costs another review cycle, and review cycles are measured in days.

---

If your app is stuck in review, has been rejected, or you would rather hand the whole publishing process to someone who has done it a dozen times, that is a service I offer. Send me the details — including the rejection email if you have one.