App Publishers: Multi-Accounting for App Store & Google Play

GetAntik editorial team · October 1, 2026 · 10 min read

How agencies and studios run multiple Apple Developer and Google Play accounts without tripping "associated accounts" bans. Practical setup guide.

A studio with five mobile games, an agency publishing apps under a client's brand, an indie developer with a separate legal entity per project — they all run into the same mundane problem: several developer consoles, several Apple IDs and Google accounts, and one browser on the computer where everything constantly gets mixed up. Here's how to set this up so you don't get flagged for "associated accounts" and don't lose access when a developer leaves mid-release.

Where multiple developer accounts come from

The reasons are almost always legitimate — nothing to do with rule-dodging:

• An agency manages apps for several clients. Each client has their own Apple Developer Program ($99/year) and their own Google Play Console (one-time $25 fee). The agency isn't the account owner — it gets access as a staff member or through a role inside the console.
• White-label publishing. One studio builds dozens of similar apps (page builders, template-based games) under different client entities — each entity is required to have its own developer account; Apple states this directly.
• Multi-brand inside one company. Different product lines get published under different developer names, sometimes deliberately, so they don't look like one assembly line in the App Store.
• Regional storefronts. The App Store covers 175+ storefronts, and some teams keep sandbox tester accounts tied to specific locales to check pricing, copy, and localized screenshots before publishing.

None of this breaks platform rules — as long as each account genuinely belongs to its own entity or is used for its stated purpose (testing, or work done on a client's behalf).

What Apple and Google actually forbid

This is worth getting precise about, because confusion here is the most expensive kind.

Apple. One Apple Developer Program per business or individual. Creating a second account for the same business to get around a rejection or a ban is explicitly prohibited — Apple calls this "circumventing review" and bans all linked accounts at once if it finds overlaps: the same bank account, the same device logged into both accounts, the same dev team without disclosed association. At the same time, having legitimately separate accounts for different clients or brands is normal — it's standard agency practice, and Apple's own program supports it (App Store Connect lets you add an agency as a "Developer" or "Admin" on someone else's account by invitation).

Google Play. The policy is similar: multiple developer accounts are allowed if they represent genuinely separate businesses or projects. But creating duplicates after an app gets removed, inflating metrics across several accounts of the same developer, or hiding the link between accounts after a policy violation — that's grounds for terminating every connected console at once.

The takeaway is simple: you're entitled to run multiple accounts, but platforms actively look for technical overlaps between them — precisely because that's how real ban-evasion schemes usually get caught. So splitting accounts across browsers, networks, and devices isn't disguise — it's hygiene. You're showing the platform exactly what you are: separate legitimate accounts, not one person hiding a connection between them.

Where things usually get tangled in practice

Three recurring situations at studios and agencies:

1. One browser for every console. A developer keeps five App Store Connect tabs open under different Apple IDs. Autofill picks the wrong email, cookies from one account leak into another session, and logging in through a shared Chrome profile can let Apple see a device+network pairing across accounts that formally belong to different clients.
2. Handoff when a contractor leaves. The freelancer who handled publishing for a client's app moves on — but their password, saved cookies, and 2FA key are still sitting in their personal browser. Reassigning everything to a new person without stalling the release doesn't always go smoothly.
3. Storefront testing. A QA engineer logs into a sandbox tester account for the German storefront, then logs into the US one in the same window — the interface language and geolocation no longer match what that test account is supposed to see, and some localization bugs go unnoticed exactly because of this.

How to organize work across multiple developer consoles

One browser profile — one developer account

The simplest and most effective fix is a separate isolated browser profile for every Apple Developer Program and every Google Play Console the team works with. Each profile locks in a set of parameters — OS, browser version, screen, timezone, and language, all pulled from the exit proxy's IP rather than copied from the employee's actual machine. This removes the most common cause of accidental overlap: the same browser "fingerprint" showing up across different client accounts.

For studios with dozens of apps and a dozen client consoles, this looks like a list of profiles with clear names ("Client A — App Store Connect," "Client A — Google Play," "Brand B — sandbox DE"), grouped by project. We covered how to keep this list manageable once profile counts get genuinely large in organizing profile pools at scale.

Proxies for regional storefronts and test accounts

If the team is checking store localization for a specific country, the tester account needs to physically connect from an IP in that country — otherwise the geolocation, timezone, and interface language Apple or Google sees won't match the claimed storefront, and part of the check loses its point. The proxy manager, with proxies bound to individual profiles and exit-IP checks, handles this directly: one proxy, one storefront, no manual VPN switching before every test.

For agencies running live consoles for multiple clients rather than test ones, proxies serve a second purpose — technically separating clients across different networks so Apple and Google have no reason to cluster unrelated businesses together. Which proxy type fits this task — residential, mobile, or datacenter — is covered in detail in proxy types for multi-accounting.

Storing 2FA and handing off access without sharing passwords

Two-factor authentication on App Store Connect and Google Play Console isn't a formality — without it, a developer account simply won't pass verification. The catch is that the 2FA key usually lives on one specific person's phone, and reissuing it from scratch when someone changes roles can cost a day or two of lost access.

A 2FA key vault tied to the profile rather than to a personal device solves this: the key moves with the profile when a project is handed to someone else on the team, and it doesn't disappear along with a departing developer. More on how the encryption and recovery work in profile security.

Roles and profile handoff between team members

At an agency juggling several client consoles, not everyone should have access to everything. Team roles with profile limits and default permissions handle this cleanly: a developer only sees profiles for their own projects, an account manager only sees client correspondence and analytics, and the GetAntik account owner oversees the whole pool.

When a project moves from one freelancer to another — which happens regularly at studios that rely on outside contractors — the profile, with all its cookies, history, and 2FA key, transfers through the standard handoff flow, with no rebuilding from scratch and no risk that the former contractor still has working access. That mechanism, and the common mistakes around it, are covered in team roles and profile handoff.

Table: scenario vs. setup

Common mistakes

Logging into a personal and a work Apple ID in the same browser window. Keychain and autofill in Safari/Chrome periodically mix up sessions, and a client account ends up carrying the developer's personal device fingerprint along with their personal autofill data.

One shared proxy or a home IP for every client console. If five different legal entities log into their Developer Programs from the same IP at the same time, that's exactly the pattern Apple and Google look for when screening for ban evasion — even if each client is entirely legitimate on their own.

Not separating test and production accounts. A sandbox tester for QA and a real developer Apple ID serve different purposes, but they often end up in the same browser profile, and test actions accidentally pollute production data.

Keeping the password and 2FA with only one person. The classic failure: the one person who can publish an update is on vacation or has quit, and the release is on fire. Solved ahead of time with properly configured role-based access, not a password in someone's personal notebook.

Attaching the same payment information to different accounts without a real need. This isn't about the browser or fingerprint anymore — it's about bank details and payout methods — but these are exactly what platforms most often use to link formally separate accounts. Profile isolation removes the technical side of the risk; it doesn't replace keeping honest, separate bookkeeping per entity.

FAQ

Can an agency get access to a client's App Store Connect without the client sharing their password? Yes — this is a built-in Apple mechanism: the client adds the agency as a user with a Developer or Admin role on their own account. A separate isolated profile with its own login works well for exactly this case: the agency doesn't hold a shared login, it signs in as its own invited user.

Does an antidetect browser remove the risk of a ban for "linked accounts"? It removes the technical cause of a false positive — overlapping browser fingerprint, IP, and session across different legitimate accounts. But if accounts belonging to the same business are genuinely being used to dodge a rejection or a ban, no amount of profile isolation makes that permitted — Apple and Google check more than just the browser; they also look at payment data, app content, and the dev team behind it.

Does every sandbox tester account need its own proxy? If the goal is to check a specific country's localized storefront, yes — the timezone, language, and geolocation in the profile need to match the storefront's country, or part of the localization check loses its purpose. For internal functional tests that aren't tied to a region, this isn't necessary.

What happens to the 2FA key and cookies when a profile is handed to another employee? The profile moves to the new person as a whole — along with the key from the vault, cookies, and login history — without needing to reissue two-factor authentication from scratch on Apple's or Google's side.

Where to start if everything right now lives in developers' heads and one shared Chrome? Start with an inventory: every Developer Program and Play Console account, which entity or client it belongs to, and who currently has access. Then move to one profile per account, migrate 2FA into the profile vault, and assign team roles. A 20-profile plan is usually enough to start with — plenty for most studios juggling a handful of clients or brands — and you can raise the limit later on the pricing page.

app storegoogle playmulti-accountingagenciesantidetect browser