Managing Multiple Apps in One Google Play Console Account: A Practical System

One Play Console account can hold many apps — but "can" and "should manage well" are different things. Once you're past three or four listings, the default dashboard becomes a swamp of release tracks, store listings, policy inboxes, and signing keys. This article lays out a practical system for managing multiple apps in a single Google Play Console account without losing track of releases, permissions, or compliance.

In short: Yes. One Play Console account can hold every app you publish, and for most small teams that is the right setup: one $25 registration fee, one identity verification, one policy inbox and one permission model. Open a second account for a separate business, a client who wants their own account, or to isolate a high-risk app from flagship products.

One dashboard can hold many listings when managing multiple apps in one Play Console account.

One account or several?

Start with the architecture decision. Google allows multiple apps per developer account, and for most indie developers and small studios, one account is the right call:

• Single $25 registration fee and one identity verification
• Consolidated policy inbox and compliance status
• One payments profile for all apps
• Shared user management — one team, one permission model

Google's Get started with Play Console guide walks through registration, the US$25 one-time fee and identity verification.

When to split into multiple accounts:

• You operate genuinely separate businesses (separate legal entities)
• A client portfolio where each client wants their own account ownership (agencies)
• Risk isolation — if one app's policy violation puts an account at risk, unrelated apps shouldn't share the blast radius

That last point deserves emphasis. One terminated account takes every app in it down. If you have a high-risk app (aggressive monetization, user-generated content, gray-area categories), consider whether it belongs in the same account as your flagship products. Risk isolation is a legitimate architectural reason for a second account — not an attempt to dodge enforcement.

How do I organise names, tracks and version codes?

Play Console's search is mediocre. Impose order yourself:

Consistent naming and track templates help when managing multiple apps in one Play Console account.

1. App names as namespaces. Use a consistent internal prefix in the app name shown in the dashboard, e.g., Studio · Fitness Tracker, Studio · Recipe Box. The public store listing name stays clean — this is just your dashboard label (you can differentiate via the app's internal naming in your own tracking).
2. Track configuration templates. Standardize your tracks per app: internal → closed → open testing → production. Don't let one app run "beta" as an open track while another uses it as closed — the inconsistency will bite you during a hurried release.
3. Version code strategy across apps. Keep version codes per-app (they must be), but adopt a shared scheme so any engineer can read one: MAJOR*1000000 + MINOR*10000 + PATCH*100 + BUILD, e.g., 2030401 = v2.3.4 build 1.

// build.gradle — shared versioning convention across your apps android { defaultConfig { // App A: versionCode 2030401 = v2.3.4 (1), App B: 1050203 = v1.5.2 (3) versionCode 2030401 versionName "2.3.4" } } 

How do I keep permissions safe across many apps?

With multiple apps and a growing team, permissions become the messiest part. Apply the principle of least privilege per app:

Least-privilege permissions matter when managing multiple apps in one Play Console account.

• Give your ASO/marketing contractor access to store listing permissions only, and only for the apps they work on.
• Give QA access to release permissions on testing tracks, not production.
• Reserve account-level admin (users & permissions management, financial data) for founders.

Play Console lets you scope user access per app — use it. A contractor who needs to tweak screenshots for App A has no business seeing App B's revenue data. (Team permissions deserve their own deep dive; the short version is: scope by app, scope by role, review quarterly.)

How do I coordinate releases across apps?

The operational risk with many apps isn't any single release — it's two releases colliding. Shared backend changes, shared SDK updates, or a policy change from Google can hit several apps at once.

Build a simple release calendar discipline:

• One release train per week, even if some apps skip it. Knowing that production pushes happen on Thursdays beats ad-hoc chaos.
• Stagger staged rollouts. Don't start a 50% rollout on two apps the same day. If a crash spikes, you want to know which app caused it.
• Shared dependency updates in one window. When you bump a major SDK (billing library, ads SDK), update all apps in the same cycle and watch crash-free rates together.

Automating multi-app releases

If you're publishing several apps, the Play Developer API is worth the setup. A small script can report the status of every app's tracks in one view:

# List releases across tracks for one app via the Edits API concept; # in practice, use fastlane supply or the Gradle Play Publisher plugin # with one service account JSON per... no — ONE service account can be # granted access to ALL your apps. Configure it once: # In Play Console: Users and permissions → invite the service account # email → grant per-app access with release permissions. # Then loop your apps in CI: for APP in com.studio.appa com.studio.appb com.studio.appc; do fastlane supply --package_name $APP --track production \ --json_key service-account.json --check_only done 

One service account, scoped per app, rotating keys on a schedule. That's the professional setup.

How do I handle compliance at scale?

Every app in your account generates its own policy communications, and Google's deadlines are per-app. Miss a "fix by" date on one app and it can escalate to the account level. Your system:

• One shared inbox for all Play Console emails (e.g., play-alerts@yourstudio.com), with filters labeling by app package name.
• A weekly 15-minute compliance scan: open each app's Policy status page, confirm green across the board.
• A data safety form template. If your apps share a tech stack, much of the Data safety section is identical. Maintain one canonical answers document and adapt per app — don't re-derive it from scratch each time.

How often should I refresh store listings?

Stale listings compound. Screenshots from v1.0 on an app now at v3.0 erode conversion. Schedule a quarterly listing refresh per app: screenshots, feature graphic, short description, and keyword pass. Batch it — doing all apps' graphics in one sitting with your designer is far more efficient than one-offs.

When have I outgrown spreadsheets?

Signs you've outgrown manual management:

• You can't name every app's current production version from memory
• Release notes are written from memory instead of changelogs
• You discover a policy email three days after the deadline
• Two apps are on wildly different target SDK versions with no plan

At that point, invest in the boring infrastructure: a release runbook, a compliance calendar, and API-driven status checks. The teams that ship reliably on Play aren't the ones with the cleverest code — they're the ones whose operational basics never slip.

If setting up this kind of multi-app publishing workflow — service accounts, track templates, permission scoping — feels like a week of yak-shaving you'd rather spend on your product, hands-on help with Google Play publishing can get the operational layer right from day one.

FAQ

How many apps can one Play Console account hold?

Google sets no published limit on apps per developer account; one account can hold your whole portfolio. The practical limit is operational: releases, permissions, policy mail and signing keys all share one dashboard, so past a handful of apps you need naming conventions, track templates and a release calendar to stay in control.

Does each app need its own $25 registration fee?

No. The US$25 one-time registration fee is paid once per developer account, not per app, and it covers every app you publish under that account. A second account — for a separate business or a client — needs its own registration, identity verification and fee.

What happens to my other apps if one app is removed or its account is terminated?

Policy action is per app when the problem is isolated to one listing, but account-level termination removes every app in that account. That is why risk isolation matters: a high-risk app with aggressive monetisation or user-generated content should not share an account with the flagship products your business depends on.

How do I keep permissions safe across many apps?

Scope every user per app and per role, following least privilege: store-listing rights only for the ASO contractor's apps, testing-track release rights for QA, and account admin for founders only. Review access every quarter and set expiry dates on contractor invites so finished engagements lapse automatically.

Can one service account publish all my apps?

Yes. Create one Google Cloud service account, invite its email under Users and permissions in Play Console, and grant it release permissions scoped per app. For a cleaner setup, use two service accounts — one for testing tracks and one for production — so a leaked testing key can never ship to production.

How often should I review store listings across a portfolio?

Schedule a quarterly refresh per app: screenshots, feature graphic, short description and a keyword pass, batched across all apps in one sitting with your designer. Stale screenshots from version 1.0 on an app now at 3.0 quietly erode conversion, and batching the work is far more efficient than one-off updates.

About the author: This guide was written by the team at Play Console Store — an independent marketplace for Google Play publishing services, not affiliated with or endorsed by Google LLC. We help Android developers with Play Console account setup, closed testing coordination, and policy compliance. Note that each developer must register their own Play Console account ($25 one-time fee).