Who Owns Your App? Why We Publish Under Your Accounts
Before we write a line of code for a new client, we set up the Apple Developer and Google Play accounts in their name, with them as the legal account holder, and add ourselves as team members underneath. That is the whole policy. It costs us the one thing most agencies quietly rely on — the ability to make leaving expensive — and it is the single decision we would defend hardest if someone asked us to change it.
This post is about why, and about what you can do if you are reading it because someone else already published your app under their account.
Ownership is four separate things, not one
"You own your app" is a sentence with four claims hiding inside it, and a firm can be truthful about one while being silent on the rest:
- The source code. Who holds the repository and who holds the copyright. This is what contracts usually address.
- The Apple Developer account. Whose legal entity signed Apple's agreements, and whose name is on the store listing.
- The Google Play developer account. Same question, different store.
- The backend. The database, the file storage, the API keys, the push-notification credentials, the domain.
A contract that assigns you the code and says nothing about the other three has given you a copy of a car with no keys and no title. You can hand the code to a new developer, and they still cannot ship an update to your existing users, because the listing that your users installed from lives in someone else's account.
That is the failure mode worth designing against, and it is why our answer starts with the accounts rather than the repository.
The account holder is the part that actually decides
Apple's developer accounts are not a flat pile of logins. Each team has exactly one Account Holder, and per Apple's own roles documentation, that person is the only one who can accept legal agreements, renew the membership, change banking details, and add the first Admin. Every other role — Admin, App Manager, Developer, Marketing, Finance — is a delegated permission underneath them.
So the practical question is not "does the contract say I own it." It is: whose name is in the Account Holder slot. If it is your development partner's, then your app's continued existence depends on them renewing a membership and accepting agreements on your behalf indefinitely.
Google Play works the same way in substance: the account is registered to a legal entity, and other people are granted per-app permissions on top.
The good news is that the correct setup is not difficult, it is just an ordering problem. You enrol. You are the account holder. You then invite your developer in as an Admin or App Manager on Apple's side, and grant scoped permissions on Google's. They get everything they need to build, upload, and submit. You keep the ability to fire them on a Tuesday and have someone else uploading by Thursday.
What it actually costs to do it this way
We would rather show you the tradeoff than pretend there isn't one.
It is slower to start. Apple requires companies and educational institutions to supply a D-U-N-S Number registered to the legal entity. Apple's D-U-N-S guidance says to "allow up to 5 business days to receive your number from D&B," then "up to 2 business days for Apple to receive your information." That is potentially a week and a half of calendar time before enrolment can even begin, sitting in front of a build we could otherwise have started. Enrolling as an individual skips it, but then the store listing shows your personal name rather than your company.
You see the platform fees as your own line items. The Apple Developer Program annual fee is 99 USD and Google Play charges a US$25 one-time registration fee, both as of August 2026. On our pricing page those sit outside the build price precisely because they are charged to your card, on your account. An agency that publishes under its own umbrella account can absorb them and look cheaper on the quote.
We give up the lock-in. If you decide after launch that you would rather work with someone else, nothing technical stands in your way. We think that is the correct incentive to be under, but it is genuinely a cost, and it is the reason this arrangement is less common than you would expect.
If your app is already on someone else's account
This is recoverable, and it is worth knowing the real mechanics before you open the conversation, because "just transfer it" is not one button.
On Apple, an app can be transferred without being removed from the App Store, and it keeps its reviews, ratings, and Bundle ID. But it has to clear a list of conditions first. Apple's app transfer criteria require that the app has had at least one version released to the App Store, that it is not available for pre-order anywhere, and that it is not sitting in any of the in-flight states — Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release, or Pending Apple Release. In-app purchase product IDs also cannot collide with product IDs already in the receiving account, and Apple Arcade apps cannot be transferred at all. TestFlight and Xcode Cloud data has to be cleared out first, and you cannot generate new promo codes afterwards.
On Google Play, per Google's transfer documentation, the original account owner initiates and the target account approves. Both accounts must be active, the target account needs the registration transaction ID to hand over, and Google's support team "reviews and replies to transfer requests within 2 business days." Ratings, reviews, download statistics, store listing content, and subscriptions come across. Payout and earnings reports do not. Test groups have to be rebuilt, and permissions for connected services like Firebase and Google Analytics need reconfiguring by hand.
Read both lists and one thing stands out: every step needs the current account holder's active cooperation. There is no unilateral path. If the relationship has already gone bad, that is the leverage you are negotiating against, which is exactly why the setup order matters more than the contract wording.
Where this makes us the wrong choice
If what you want is for the app to be somebody else's problem entirely — you never log into a console, you never see a renewal email, you never think about a D-U-N-S Number — then a white-label or reseller platform that publishes your app under their developer account is genuinely the simpler product, and it will usually be cheaper too. That is a real, legitimate trade. You are buying convenience with portability. Just make the trade knowingly, and ask the direct question before you sign: if I leave in two years, does my app and its install base come with me? A clear no is fine. A vague answer is the problem.
Likewise, if you already have a developer inside your business who lives in these consoles daily, you do not need us to hold your hand through enrolment. Do it yourself in an afternoon.
The order that avoids all of this
Enrol first. Build second. Publish third. Start the D-U-N-S request the same week you start talking to a developer, so it runs in parallel with scoping instead of blocking the build. Add your developer as a team member, never as the account holder. Keep the backend and the domain in accounts registered to you as well, since those are the pieces people forget until a renewal fails.
If you are working out what the whole path looks like, our walkthrough of how to publish an app to the App Store and Google Play covers the submission side in order, and the free tool library has a privacy policy generator that produces the store disclosure answers alongside the policy itself.
And if you want to know what your build would cost with the accounts in your name from day one, the app brief takes about three minutes and a free intro call turns it into a fixed written quote.
Your app. In the stores. Done for you. US APP Team designs, builds, and launches your iOS and Android app for a fixed price. Start your app brief or book a free intro call — both are free.
Want to poke around first? Every tool in our free tool library runs in your browser with no signup: an app cost calculator, an app name generator, and a privacy policy generator.
