How to publish your first app on Google Play: the complete checklist

Use a Google account you will still control next year, with two-factor authentication on. Registration is $25, once. Have a photo ID, and for a company proof you represent it. The privacy policy has to be a public URL about this app.

Choose personal or organization before you pay. Organization needs a D-U-N-S number and takes longer, but it is not subject to the 12-tester gate that personal accounts created after 13 November 2023 must pass. A company should enroll as an organization rather than convert a personal account later.

You need an Android App Bundle from Android Studio or CI. There is no Mac requirement. Pick the package name now — reverse-DNS, no hyphens — because the first upload locks it. The appId validator checks the iOS rules at the same time.

The display name is public on every listing. Pay the $25; a failed payment leaves publishing locked. Google then checks a photo ID and a phone or email challenge. The name on the ID has to match. Organization accounts are also checked against D-U-N-S. Do not open a second account while the first is pending.

Android developer verification is a separate rule. Since 30 September 2026, apps installed from participating stores, including Play, in Brazil, Indonesia, Singapore, and Thailand must belong to a verified developer. The same requirement is set to expand globally in 2027. Play developers finish it inside Play Console; Google registers that account instead of sending Play-only apps to another console. If those four countries are your first audience, do this before you share an install link. An unverified app fails on the device.

A verified account opens onto a task list. That list is the rest of this checklist.

The developer account and the account that receives money are different. You need a merchant profile only if the download has a price or the app sells in-app products or subscriptions. A free app with no billing can run an internal test without it.

When you do set it up, the legal seller name should match the developer account, and the bank account has to be able to receive payouts in your country. Tax questions follow. Merchant review can take a few days and can block a paid production release even after the closed test is done. Start it in parallel with the content forms if you know you will charge.

CapWrapp’s upload does not need this profile. The first real purchase does.

The dialog asks for the name, the default language, app or game, and free or paid.

The name can change later, still inside the 30-character listing limit. The default language is the one you write first.

Free or paid cannot be changed later. A free app can add in-app products. It cannot later be given a download price, and a paid app cannot be switched to free. Either change means a new package name. Most first apps should be free, with money in products if you need it.

You also confirm the developer program policies and US export laws. Those are declarations. After you accept, the app is a draft and the dashboard lists the store listing, app content, and a release. The package name is not typed here. It is read from the first bundle you upload, and then it is permanent.

Upload an Android App Bundle, not an APK. Since 31 August 2026, new apps and updates must target Android 16 (API 36) or higher. Wear OS and Android Automotive stay at API 35; Android TV and Android XR at API 34. A phone app on API 35 is rejected at upload. Set targetSdkVersion 36. The Play Console wording is target API level requirements.

Play App Signing is the default. Google holds the key users install; you hold one upload key. A second keystore is rejected as the wrong key. A lost upload key can be reset. See Play App Signing.

CapWrapp creates that upload key and uploads to the internal track. It does not submit the listing or production. Wiring is in the Google docs. Upload before you create in-app products: billing setup wants a bundle that already includes Play Billing.

Production stays blocked while any card is incomplete. Open each one even when the answer is no. The index is Prepare your app for review.

Privacy policy

A public URL that describes this app and matches Data safety. If you touch sensitive data, the same policy must open inside the app.

App access

A working reviewer username and password if anything is behind login, or an explicit “no login”. Reviewers will not register and will not email you.

Ads declaration

Yes or no. Banners, interstitials, native ads, and ad SDKs all count, and yes shows “Contains ads”.

Content rating

The IARC questionnaire. No rating means no Play listing. Hiding user-generated content or gambling can get the app removed later. Policy: content ratings.

Target audience and content

The ages you designed for. Locked until privacy, ads, and app access are saved. Including children pulls in the Families rules on ads and data. Do not tick under-13 to look friendly. Form: target audience and content.

Data safety

For each type: collected, shared, optional or not, and why. SDKs count — Firebase, RevenueCat, ads, crashes. An advertising ID you read is a device identifier. The public label has to match the privacy policy. Fields: Data safety.

Advertising ID

Say whether you use it. If yes, Data safety must agree, under the advertising ID policy. Some analytics libraries read it unless you turn that off.

Government, financial features, health, and news

Separate cards for government services, financial products (lending, banking, crypto, trading), health, and news. “No” still has to be saved. News is named on the prepare-for-review page; the others sit on the same list.

Sensitive permission declarations

Background location, SMS and call log, all-files access, exact alarms, and foreground service types need a reason, often with a short video. If you do not need the permission, remove it. A wrapped site almost never needs SMS or all-files access.

Limits that matter on a first listing: name 30 characters, short description 80, full description 4,000. The short text is what search shows. The icon is a 512 × 512 PNG. The feature graphic is 1024 × 500; do not put fine print in it.

Phone screenshots: at least two, JPEG or 24-bit PNG without alpha, each side from 320 to 3840 pixels, and the long side at most twice the short side. A modern iPhone capture is often taller than 2:1, and Play rejects it. The screenshot checker flags that and can export a Play-safe frame. Add a tablet set only if the app supports tablets. A contact email is required. Asset rules are in preview assets.

Save the listing even if the copy will change. An empty listing blocks review the same way an empty content form does.

New apps often default to every country Play supports. Remove one when you lack a language, a license, or a legal basis to operate there. Adding a country later is easy. Selling where you are not allowed to is not.

The download price follows the free-or-paid choice from app creation. Free stays free. Paid needs the merchant account, a default price, and any per-country overrides. In-app prices are set on the products, not here.

Country availability applies to every track. Set the real list before you send a closed-test link, or testers outside it cannot opt in.

Internal testing (up to 100 emails) is how you prove the bundle installs. Testers opt in from a link. CapWrapp uploads here. This track does not unlock production.

Personal accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in for 14 consecutive days before production access. Organization accounts and older personal accounts are exempt. Confirm yours in the console. Setup: open, closed, or internal test.

An email on the list is not opted in until that person opens the link. Someone who leaves and returns starts their 14 days over. When you apply, 12 people must still be in, for the preceding 14 days. Recruit 14 to 16. They need a Google account in a country you distribute to.

Use a closed track for the clock. A new build on that track does not zero it; testers who opt out do. Then apply for production access and describe what testers found. Review of that application can take about a week. Access lets you open the production track. It is not the release. The 12-tester countdown gives the day you can apply and drafts the answers.

Products stay incomplete until Play has an uploaded bundle that contains the billing library. That is why the internal build comes first. Create products with the same ids the app requests.

One-time products need a price and a title. Subscriptions need a base plan, and an offer if you have an intro price. Activate them. Draft products are not for sale.

You can run the 14-day test without products unless the purchase is what you want testers to try. If it is, add them as license testers so they are not charged. A paywall with nothing behind it looks broken on the production-access questionnaire. Digital goods in the app go through Play Billing. A card form for a digital subscription is a policy problem, not a faster launch.

Create the release only when the dashboard shows no blocking errors. Pick the bundle you already tested, write release notes, and choose a rollout percentage. Starting at 10 or 20 percent means a bad crash does not reach everyone. You can halt or raise the percentage without rewriting the listing.

Review reads the listing, the content forms, and the app. A Data safety mismatch or a login the reviewer cannot use comes back here even after a clean closed test.

Managed publishing holds an approved app until you press Publish. Turn it on before you submit if the launch hour matters. Google’s note is managed publishing. Leave it off only if you are happy for the app to appear the moment review finishes.

A later update repeats the release, not the account. The iPhone path is the App Store submission checklist. The internal bundle from a GitHub repo is Lovable to App Store and send a build.