app publishing

It means paying someone who already owns a verified Google Play developer account to publish your app under their account. You build the app; they (or you, with delegated access) push it live through their console. It's essentially managed publishing — you get a live listing without opening and seasoning your own account. Full explainer here.

Publishing an app on Google Play takes five steps: (1) open a Google Play developer account (a one-time $25 fee), (2) build a signed Android App Bundle (.aab), (3) create the app in Play Console and complete the store listing (title, descriptions, screenshots, icon, feature graphic), (4) fill in the content-rating, Data safety and target-audience declarations, and (5) roll out a release to a testing track and then to production. New personal accounts must also run a closed test with at least 12 testers for 14 days before they can publish to production.

Google charges a one-time $25 registration fee to open a developer account — there is no annual renewal (unlike Apple's $99/year). After that, publishing is free; Google only takes a 15–30% service fee on paid apps and in-app purchases. The bigger hidden cost for new accounts is the 12-tester / 14-day waiting period before an app can go live.

Yes — every app on Google Play is published under a verified Google Play developer account, and there is no way to list an app without one. You either open your own (the $25 fee, identity verification, and the 12-tester rule for new accounts) or publish through someone who already holds a verified account. See the options for publishing without your own account.

Yes — you can publish through an existing verified developer account instead of opening your own, which is exactly what “renting a Play Console” means. You build the app; a verified publisher pushes it live under their seasoned account, skipping the new-account 12-tester / 14-day gate. The safest version is the live-and-transfer model, where the listing ends up on a console you own.

Most reviews finish within a few hours to 3 days, though Google officially says it can take up to 7 days or longer for brand-new developer accounts or apps that need extra checks. First submissions and sensitive categories (finance, health, apps for children) take the longest. A seasoned, established account usually clears review faster than a brand-new one.

An APK (Android Package) is the installable file that runs on a device; an AAB (Android App Bundle, .aab) is a publishing format you upload to Google Play, which then generates and signs optimised APKs for each device. Since August 2021, new apps must be published as AABs — you can no longer upload a plain APK for a new app. APKs are still used for sideloading and direct distribution.

Google Play requires the App Bundle so it can deliver smaller, device-optimised downloads through Play Feature Delivery — users only download the code and resources their specific device needs, cutting download size by around 15% on average. The trade-off is that Google must hold your app-signing key (Play App Signing) to repackage and sign the bundle for each device.

Play App Signing is the system where Google manages your app's signing key and uses it to sign the APKs generated from your uploaded App Bundle. You upload with an “upload key”, and Google re-signs with the secured app-signing key it stores — mandatory for new apps. It lets Google optimise delivery and recover your key if you lose it, but it also means Google holds the master signing key.

In Android Studio, choose Build → Generate Signed Bundle / APK, select “Android App Bundle”, create or pick an upload keystore, and build the release .aab. From the command line you can run ./gradlew bundleRelease after configuring signingConfigs in build.gradle. Upload the .aab in Play Console and keep your keystore and passwords backed up — losing the upload key needs a reset request to Google.

A complete listing needs an app title (max 30 characters), a short description (max 80), a full description (max 4,000), a 512 x 512 px icon, a 1024 x 500 px feature graphic, at least 2 phone screenshots (up to 8 per device type), a category, contact details and a privacy-policy URL. You must also complete the content rating questionnaire, the Data safety form and the target-audience declaration before you can publish.

App icon: 512 x 512 px 32-bit PNG. Feature graphic: 1024 x 500 px. Phone screenshots: between 320 px and 3,840 px per side, JPEG or 24-bit PNG, 2–8 per type. You can also add 7-inch and 10-inch tablet screenshots. A feature graphic is required for your app to be eligible for featuring on Play.

Put your most important keyword in the app title (max 30 characters) and lead the short description (80 chars) with the core benefit plus a primary keyword — both carry the most ASO weight. Use the full description (4,000 chars) to naturally repeat two or three target keywords, describe features in scannable paragraphs and end with a clear call to action. Avoid keyword stuffing — Google can suspend listings for it.

The Data safety form is a mandatory declaration in Play Console where you disclose what user data your app collects, why, whether it is shared with third parties and how it is protected. It powers the “Data safety” section shown on your store listing. Inaccurate answers are a policy violation that can get the app removed, so it must match your app's real behaviour and your privacy policy.

Since 2023 Google requires every developer to verify their identity — legal name, address, phone and email, plus a D-U-N-S number for organisations — before they can publish. Personal accounts created after November 2023 must also complete the 12-tester / 14-day closed test. Verification can take a few days; if it is incomplete, publishing is blocked and the account can eventually be closed.

Most suspensions come from policy violations — malware or deceptive behaviour, impersonation, repeated content-policy strikes, payments fraud, or breaking the Developer Distribution Agreement. A termination usually bans the underlying Google identity from Play for good, and every app on that account goes down with it. That shared-fate risk is why careful publishers prefer the live-and-transfer model over one shared account.

Yes — Google offers an official app-transfer process that moves an app, along with its reviews, installs and history, from one developer account to another without users noticing. Both accounts must be in good standing and the transfer is requested through Play Console. This official feature is what makes the legitimate live-and-transfer model possible: publish on a seasoned account, then transfer the app to one you own.

Yes — you can publish through someone else’s verified Google Play developer account, an arrangement usually called renting a Play Console or managed publishing. You build the app and a verified owner pushes it live under their account, which skips opening and seasoning your own account and the 12-tester / 14-day wait. The safest version is the live-and-transfer model, where the app is finally transferred to an account you own. ConsoleMint offers this as a service.

Yes — no-code and low-code builders such as app builders, WebView wrappers and PWA-to-APK tools can generate a publishable Android App Bundle without writing Java or Kotlin. You still need a Google Play developer account (or a rented one), a complete store listing, a privacy policy and the Data safety and content-rating declarations. The build is the easy part; passing Google’s policy review is what most no-code publishers underestimate.

No — you can publish as an individual/personal developer or as an organisation. A personal account needs identity verification (name, address, phone); an organisation account additionally needs a D-U-N-S number and shows the company name as the developer. Choose organisation only if you want the business name on the listing; the account type cannot be changed after creation.

The Google Play developer registration fee is a one-time $25 payment, not a subscription — you pay it once when you create the account and never again. Apple’s equivalent is $99 per year, so Google is far cheaper over time. The $25 does not cover the 15–30% service fee Google takes on paid apps and in-app purchases.

Publishing from India follows the same worldwide process: create a Google Play developer account, pay the one-time $25 fee (charged in USD to an international-enabled card), complete identity verification with an Indian address and phone number, then upload your signed AAB and store listing. To receive earnings you also add a payments profile with an Indian bank account and PAN. Many Indian indie developers skip the new-account 12-tester / 14-day wait by publishing through a rented, seasoned console first.

To receive money from paid apps or in-app purchases you need a Google payments profile linked to an Indian bank account, and Google collects your PAN for tax reporting. Free apps with no in-app purchases need no payments profile at all — only the one-time $25 registration. Earnings are paid out monthly once your balance crosses the payout threshold, converted to INR at Google’s exchange rate.

A D-U-N-S number is required only for organisation (company) accounts, not for personal/individual developer accounts. Indian companies can request a free D-U-N-S number from Dun & Bradstreet, which can take up to 30 days. If you are an individual developer, you skip D-U-N-S entirely and verify with your personal identity instead.

The most common rejection reasons are a missing or invalid privacy policy, a Data safety form that doesn’t match the app’s behaviour, broken or crashing functionality, misuse of permissions, misleading metadata or screenshots, and intellectual-property or impersonation issues. Google emails the exact policy that was violated; fix that specific item and resubmit. Repeated rejections for the same issue can escalate into a policy strike against the whole account.

Add a publicly reachable privacy-policy URL that names your app, lists what data it collects and how it is used, then paste that URL into Play Console under Store presence → Store listing and in App content → Privacy policy. The policy must sit on a live, non-editable page (not a Google Doc set to edit) and must match your Data safety answers. Once both agree, resubmit for review.

A policy strike is a formal warning Google issues when an app violates a Play policy, and strikes accumulate against the developer account. Enough strikes — or a single severe violation such as malware or fraud — leads to app removal and eventually account termination, which bans the underlying Google identity from Play permanently. Because every app on a terminated account goes down together, careful publishers isolate risk using the live-and-transfer model.

“Pending publication” means the app passed review but Google is still propagating it, which normally takes a few hours but can stretch to up to 7 days for brand-new developer accounts. Accounts created after November 2023 are throttled the most, while established accounts publish almost immediately. If it exceeds 7 days, check for an unfinished declaration (Data safety, content rating or target audience) silently blocking the release.

Personal Google Play developer accounts created after November 2023 must run a closed test with at least 12 testers who stay opted in for 14 continuous days before the app can go to production. The rule is Google’s way of vetting new individual developers and is the single biggest reason a new account cannot launch instantly. Organisation accounts and seasoned accounts are exempt, which is why many developers publish through an established console to skip the wait.

Recruit testers from friends and colleagues, developer communities (Reddit r/androiddev, Discord and Telegram testing-swap groups) or a small paid tester service, then add their Google-account emails to a closed testing track or a linked Google Group. All 12 must opt in and keep the app installed for the full 14 days — if someone drops out, the 14-day clock can reset. Line up 15–20 sign-ups so you keep at least 12 active throughout.

You cannot waive the 14-day closed test on a new personal account — Google enforces it before granting production access. The only legitimate way to launch without it is to publish through an account that is not subject to the rule: an organisation account or a seasoned developer account. Publishing on a rented, established console and then using Google’s official app transfer to move the app to your own account is how developers launch this week instead of next month.

The cheapest way is to pay Google’s one-time $25 registration fee and publish under your own account — there is no ongoing charge and no revenue share on free apps. Budget for the hidden cost: the 12-tester / 14-day closed test on new personal accounts, and identity verification. If you cannot wait or cannot verify (no accepted ID, no D-U-N-S for an organisation account), the next-cheapest route is a one-off publish on an established console.

The realistic alternatives are three: publish through an established developer account (an agency, a publisher or a console-rental provider) and later transfer the app to yourself; register an organisation account, which skips the 12-tester rule but needs a D-U-N-S number; or distribute outside Play on Amazon Appstore, Samsung Galaxy Store, F-Droid or direct APK download. Only the first two put you on the Google Play Store itself. For most solo developers who need Play reach this month, publishing via an established console and then using Google’s official app transfer is the shortest legitimate path.

Not directly — every app on Google Play sits under some verified developer account, so an app cannot exist without one. What you can avoid is opening and verifying your own. Publishing under an existing account (a publisher, an agency, or a rented console) is how developers ship without registering, and Google’s built-in app transfer can later move the listing to your account without losing installs, reviews or the package name.

Yes, and it happens constantly — agencies, studios and publishers ship client apps under their own account every day. The account owner is the party Google holds responsible, so they carry the policy risk and their name appears as the developer on the listing. Do it with a written agreement covering who owns the package name, the signing key and the listing, and how the app gets transferred out if you part ways.

You can avoid paying it yourself, but somebody has paid it — the fee is charged once per developer account, so publishing under an existing account means it is already covered. There is no legitimate waiver or free tier for a personal account, and services promising to bypass the $25 charge are scams. If the fee itself (rather than the wait or the verification) is the blocker, publishing through an established console or an organisation you already work for is the honest way around it.

The fastest legitimate route is to publish under an account that is already verified and past the 12-tester gate — then your only wait is Google’s review, usually a few days. A brand-new personal account cannot beat that: it must complete identity verification and a 14-day closed test with 12 testers before production opens at all, which is roughly a month minimum. Have your store listing, screenshots, privacy policy and Data safety answers ready before you upload; incomplete declarations are what actually stall most launches.

Yes. An agency can publish under its own developer account and later hand the app over using Google’s official app transfer, which moves the listing, installs, ratings and reviews to the client’s account intact. Alternatively the client opens the account and the agency is added as a user with Release manager permissions — cleaner ownership, but the client then has to clear verification and, if the account is new, the 12-tester rule. Agencies on a deadline usually publish first and transfer after.

Freelancers generally use one of three routes: get added to the client’s console as a user with release permissions (best when the client already has an account), publish through a publisher or console-rental provider and transfer the app to the client at handover, or open their own account and keep client apps on it. The third is the trap — one client’s policy violation can strike an account carrying every other client’s app. Keep client work off a shared personal account.

Yes — use Users and permissions in Play Console to invite them by Google account and grant a scoped role such as Release manager (upload and roll out builds) or Store listing manager (edit the listing only). This is the sanctioned way to let a developer, agency or publisher work on your app, it leaves an audit trail, and access can be revoked instantly. Sharing your actual login is both a policy violation and how accounts get hijacked.

Yes — Google Play does not care which tool built the app, only whether it meets policy. Apps from no-code builders get removed for the same reasons everything else does: they are thin wrappers with little original value, they misdeclare data collection, or they lack a working privacy policy. If your no-code app has real functionality beyond a template, it will pass. Add genuine features, original branding and honest Data safety answers before submitting.

Yes, but a plain WebView wrapper around a website is the single most-rejected app type under Google’s Minimum Functionality / repetitive-content policy. To pass, the app has to do something the browser cannot: push notifications, offline caching, native navigation, device features, or an account-bound experience. Wrap-and-ship is what gets rejected; a WebView shell with real native capability around it is published every day.

Most reviews finish in a few hours to 7 days. Established accounts with a clean history are typically reviewed fastest, while new developer accounts routinely see the full 7 days and sometimes longer on the first submission. Updates to an already-live app are usually faster than a first release. If you are past 7 days, look for an incomplete declaration — Data safety, content rating or target audience — silently holding the release.