policy

Renting itself isn't a crime — it's a commercial arrangement. The grey area is Google's own terms, which are built around one verified owner per account. So it's legal in the everyday sense, but it operates in the margins of Google's policies. Keep what you publish clean and compliant.

It sits in a grey area. Google's Developer Distribution Agreement restricts sharing and transferring account access. Renting doesn't get an app removed by itself, but the listing legally lives under someone else's verified identity, and Google can act on the account if its policies are broken.

An app is removed for breaking content policy, not for the rental itself. The catch is that if the account is suspended for any reason, every app on it can go down too. Publish only what would pass review on your own account.

New personal Google Play developer accounts must run a closed test with at least 12 testers for 14 continuous days before they can apply for production access. It's the main reason people rent an established account to launch quickly.

The account owner does — their verified identity is what's on file. As the renter you don't re-verify, which is part of the appeal, but it also means you're relying on someone else's verified standing.

A D-U-N-S number is a business identifier Google requires for organisation developer accounts. You don't need one to rent, but if you ever set up your own org account, that's part of the process.

No. It must still follow Google Play policies. Renting never launders a rule-breaking app — a policy violation is just as removable on a rented account, and it puts the whole console at risk.

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.

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.

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.

Buying an account is riskier than renting or publishing through one. A sold account still carries the seller’s verified identity, and because Google now requires ID verification tied to a real person, an account whose owner-of-record is someone else is one verification prompt away from being frozen — taking every app on it down with it. Marketplace accounts also often arrive with a hidden strike history. If you need Play access without your own verification, publishing on an established console and transferring the app out leaves you with a clean account in your own name.

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.

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.