Who owns the App Store account: you or the company building your app
Pedro CunhaPublished on updated on 8 min read
In short
The developer account is the public record of who owns an app — and whoever controls the account controls the product. What matters isn't which account the app is born in, but which account it ends up in, whether yours started being opened on day one, and whether the migration is a planned step in the contract. We've run that full cycle: the transfer preserves ratings and your installed base, and it breaks specific things that need to be mapped beforehand.
The question almost nobody asks before signing#
When a company hires someone to build a mobile app, the negotiation revolves around scope, timeline and price. Almost nobody asks which developer account the app will be published under — and that is the question that decides who owns the product in the end.
The developer account is not an operational detail. It is the public record of who owns that app, and it is where the things you cannot recreate later are kept: the store listing, accumulated ratings, version history, the app's signing certificates, and the tax details that receive the money, when there is any.
The short answer is: the account has to end up in your company's name. The useful answer is more interesting, because the path there is rarely direct.
What the developer account actually holds#
It is worth understanding what is at stake before deciding where the app lives.
| What stays in the account | Why it matters |
|---|---|
| The app's store listing | it is the product's public address, with its own URL |
| Ratings and reviews | accumulated reputation, and there is no way to carry it over by hand |
| Version history | the record that the product is actively maintained |
| Signing certificates | without them nobody ships an update |
| Tax and banking details | whoever receives the money, when the app sells |
| Identifiers and credentials | Bundle ID, notification keys, subscription secrets |
None of these can be recreated from scratch for free. A new listing means starting from zero on ratings — and ratings are one of the few app assets you can neither buy nor accelerate.
The two possible arrangements#
There are two honest arrangements, and the difference between them is not ideological — it is about scheduling.
| Wait for your account to be ready | Launch via the builder's account and migrate | |
|---|---|---|
| At the start | the launch is held hostage by company registration | both tracks run in parallel |
| During the project | you are the owner from day one | the builder operates without a middleman |
| At the end | nothing to do | there is a migration, with a trigger and a date |
| Real risk | weeks idle waiting on paperwork | never getting the migration, if it isn't in the contract |
The third arrangement — publishing under the builder's account and leaving it there — isn't in the table because it isn't a path, it's a dependency. That is the one that creates the bad conversation three years later.
How we do it: two tracks in parallel#
At Epicora the process is this, and it exists because paperwork and launches run on different clocks.
The client's account starts being opened on day one. That includes the D-U-N-S number, the Apple account and the Google account, all in their company's name. This track is slow and has nothing to do with code: it is registration, identity verification and legal-entity validation, and each of those steps has its own response time.
Publishing does not wait for that track to finish. The app is published first through Epicora's account, which is already verified and operational — and that is how the first submission, the store review and any review fixes happen without being held hostage by an external registration.
When the app stabilises, the migration happens to the client's accounts, which by then already exist and are already verified.
We have run this full cycle. The ProHire app was born published under Epicora's account and was transferred to the company's account — today, if you open its App Store listing, the developer shown is ProHire's legal entity, not ours. And what matters most is what did not happen during the transfer: nobody had to reinstall anything, the ratings stayed, and the app kept receiving updates through the same channel.
The point that matters to a buyer is not the arrangement itself — it is the criterion it reveals. If the partner didn't start opening your account on day one, their schedule is already wrong, even if the app ships on the agreed date. The question to ask at a kickoff meeting is literal: is my developer account already being opened?
How the migration actually works#
Here is what decides whether "migrate later" is a plan or a promise. Both stores document the procedure, and it is reasonably generous with what matters.
What survives. Apple documents that a transferred app keeps its ratings and reviews, retains the same Bundle ID — which cannot be changed — and that users continue receiving updates normally. Google Play documents that users, statistics, data, comments, ratings and subscriptions move with the app. In practice, anyone who already installed it does nothing and notices nothing.
What stays behind or has to be redone. It is a short, specific list, and it is where the work lives:
| Item | What the migration requires |
|---|---|
| TestFlight (Apple) | must be turned off before the transfer |
| Auto-renewable subscriptions | generate a new shared secret in the destination account |
| Sign in with Apple | ungroup and generate a transfer identifier |
| Apple Pay | create a new Merchant ID in the destination account |
| App Groups | delete at the origin and register at the destination |
| Previous sales reports | remain with the transferring party |
| Test groups (Google) | have to be recreated |
What we saw in practice. In the ProHire app transfer, what the documentation promises held up: the installed base didn't notice, the ratings stayed, and updates kept shipping normally. The real work was the right-hand column of the table above — the list of credentials and identifiers to redo.
The procedure. On Apple, the account holder of the origin account initiates the transfer and the account holder of the destination account accepts — provided the app meets the transfer criteria published by the company. On Google Play, it is a request that requires the registration transaction ID of both accounts and goes through approval, with support responding within two business days.
None of this is a blocker. But notice what the list means: the migration is plannable and not free. An app with recurring subscriptions and social login is more work to migrate than a simple brochure app — and that is an argument for deciding early, not for postponing.
What the builder can do without owning anything#
The most common argument for leaving the app in the builder's account is operational: "but then they can't work". It doesn't hold.
Both stores have roles designed for exactly this. In App Store Connect the partner comes in as Admin; in the Google Play Console, as Release Manager. With those roles they create and upload builds, submit for review, respond to store requests, manage the listing and publish versions — everything except owning it. When the contract ends, you remove the access and the app feels nothing.
Ownership and operation are separate layers. Confusing the two is what produces the bad arrangement.
The shortcuts that don't work#
Two paths look like savings and aren't.
TestFlight is not a production channel. It is Apple's testing tool, and it is excellent at that. But a build distributed via TestFlight expires in 90 days — when it expires, the app simply stops opening for whoever installed it that way. Distributing your company's production app through TestFlight means scheduling one day, every quarter, when everything stops.
The Apple Developer Enterprise Program is not a way to skip the store. It requires the publishing company to have 100 or more of its own employees and restricts distribution to internal staff of that same company. Using it to distribute an app to clients or third parties is misuse — and the documented consequence is revocation of the certificate, which takes down every app signed with it at once. When a partner concentrates several clients on one such certificate, one client's problem becomes everyone's problem.
What to put in the contract#
Four clauses settle the whole matter, and all of them fit in a buyer's language:
- Final ownership belongs to the client. The product's Apple and Google accounts are registered in your company's name, and that is where the app ends up.
- Opening the accounts starts at the beginning of the project. With a named owner on both sides, because D-U-N-S and company verification don't depend on code and don't speed up at the end.
- If there is an initial publication through the partner's account, there is a migration — with a trigger and a deadline. "When the app is stable" is an acceptable trigger as long as stable is defined; "when we get around to it" is not.
- Handover of access and artefacts at closing. Certificates, keys, identifiers and the list of special capabilities the migration requires — because Apple's own documentation puts that information handover on whoever is delivering.
The criterion, in one sentence#
Don't ask whose account it is today. Ask which account the app will end up in, when yours started being opened, and what triggers the migration — and ask for all three answers in writing.
The rest is execution detail. This is ownership.