Owning the app is three things decided in three different places: the code, in the contract; the store listing, in the developer account; and the ability to ship the next version, in the signing certificates — 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.
"Do I own the app?" is three questions, not one#
Owning the app a developer built for you bundles three different things, decided in three different places — and it is entirely possible to get the first one right and lose the other two without noticing.
| Layer | What it is | Where it is decided |
|---|---|---|
| The code | what was built, and the right to use it, change it and take it to another supplier | in the contract, in the assignment clause |
| The store listing | the product's public address, the ratings and the version history | in the developer account the app was published under |
| The ability to ship | being able to push the next version without depending on a third party | in the signing certificates and the account's access roles |
Contracts usually cover the first row and never mention the other two. That is where the uncomfortable situation comes from: you can have a perfectly written code assignment and still not own the product, because the listing the public knows, the ratings you accumulated and the certificates that sign the next update all live in an account that isn't yours.
They are separate questions and both are worth asking. The code answers "can I take this with me?". The account answers "is the product that's live actually mine?". The rest of this article is about the second one — the one almost nobody negotiates.
What the developer account actually holds#
The developer account holds what cannot be recreated later: the store listing, the accumulated ratings, the version history, the app signing certificates and the tax details that receive the money. It is the public record of who owns the app, not an operational detail of the project. When the app sells something inside it, that revenue is what the store takes a commission on, and what pays and what does not is covered in when your app pays a commission to Apple and Google.
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 scheduling, not ideology: wait for your company's account to be ready before publishing, or publish through the builder's account and migrate later. The second is only safe when the migration is agreed in writing and your account is already being opened.
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 — and it is the same trap that decides the platform of a company website, in a different product.
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#
Transferring an app between accounts is a procedure both stores document, and it preserves what matters. Apple keeps ratings, reviews and the same Bundle ID, which cannot be changed; Google Play carries over users, statistics, comments, ratings and subscriptions. People who already installed it do nothing and notice nothing.
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 builder does not need to own the account in order to work. On App Store Connect the vendor joins as Admin, and on Google Play Console as Release Manager: with those roles they create and upload builds, submit for review, manage the listing and publish versions — everything except ownership. When the contract ends, access is removed and the app feels nothing.
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. It is the opposite of what happens when the dependency sits inside the system itself, and changing suppliers turns into a replacement project.
Ownership and operation are separate layers. Confusing the two is what produces the bad arrangement.
The shortcuts that don't work#
TestFlight is not a production channel: builds distributed through it expire in 90 days, and when they do the app simply stops opening for whoever installed it that way. Shipping a company's production app over TestFlight means scheduling one day per quarter on which everything stops.
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 right path for each case, from a public app to an app for a B2B client, is in why TestFlight is not a way to distribute your company's app.
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.