Here’s a conversation we’d rather not keep having. A founder’s relationship with their developer ends, sometimes badly and sometimes just because the freelancer took a full-time job. Then the founder finds out the app is listed under the developer’s Apple account, the domain renews on the developer’s credit card, and the production database sits in a cloud account they’ve never logged into. They paid for the product. On paper, somebody else controls it, and before anything else can happen they have to transfer app ownership from agency and freelancer accounts back into their own.
Usually nobody meant any harm. The developer registered things themselves because it was faster in week one, and nobody went back to fix it. This checklist covers the five accounts that cause the most trouble, what it takes to get each one back, and one contract clause that stops it happening again.
How to transfer app ownership from agency accounts, and what each one costs
1. App Store and Google Play developer accounts
If your app was published under your developer’s Apple Developer or Google Play Console account, then as far as the stores are concerned, it’s their app. You can move it. Both Apple and Google have app transfer processes. But the current owner has to start the transfer, and both accounts have to be in good standing. On Apple’s side, some app setups can block or complicate a transfer. If your old developer is slow, unreachable, or annoyed with you, you’re stuck. So start this one first.
If the transfer fails, you publish the app again under a new listing. That means losing your reviews, your ratings, and your search ranking, and asking every current user to download a different app. For a consumer product, that can undo months of growth.
2. Signing keys
Few founders have heard of this one. On Android it’s the most serious. Every app update has to be signed with a cryptographic key that proves it came from the same publisher. On iOS, whoever holds the developer account can issue new certificates, so if you get the account back, you get signing back. On Android it depends on how the app was set up. Google now manages the main signing key for most apps through Play App Signing. Older apps, or apps where the developer opted out, rely on a keystore file on someone’s laptop. If that file and its password are gone, you can never update that app listing again.
Push notification keys, API keys for maps and payments, and OAuth client secrets have the same problem on a smaller scale. None of them is hard to replace. Finding every one of them is what takes the time.
3. Your domain
If the domain is registered in your developer’s registrar account, they control your website, your email (through its MX records), and any login links your app sends out. Moving a domain requires an authorization code from the current account holder. Registrars also commonly block transfers for 60 days after a domain is registered or moved. If the domain expires on their card while you’re negotiating, someone else can register it.
4. Cloud hosting
Your servers, databases, file storage, and backups live somewhere: AWS, Google Cloud, Firebase, a VPS provider. If that account is in your developer’s name, it’s also billed to them, which means your whole product disappears the day they stop paying. Some providers make it easy to add a new owner. Firebase and Google Cloud, for example, let an existing owner grant ownership to another user. But if the account is really theirs, you’re looking at a migration: copying databases, re-creating storage buckets, updating every configuration value, and scheduling downtime. That’s engineering work, done under pressure.
5. The code repository
A zip file of the code is not the same as owning the repository. The repository holds the full commit history, the pull requests that explain why decisions were made, the CI/CD pipelines that build and ship the app, and the secrets those pipelines need. When the repo belongs to a freelancer’s personal GitHub account, a handover usually means a snapshot with no history and deployment scripts that don’t work, because they pointed to credentials you never had. Whoever you hire next spends their first weeks working out how the app gets built instead of improving it. Ask for a transfer of the repository itself, not a download.
Why this happens even with good developers
Setting up accounts is the first thing that happens on a project, and it happens before anyone thinks to ask about ownership. Apple’s developer enrollment for an organization can take a while because it requires business verification. A developer who wants to show progress in week one will reasonably just use the account they already have. The shortcut makes sense in the moment. Nobody goes back and undoes it.
So when you’re comparing freelancers, agencies, or an in-house hire, ask this early: “Whose name will each account be in?” A good team will answer right away and won’t mind being asked.
The one clause to add to your contract
You don’t need a long IP section to fix this. You need one clause that’s specific about accounts, not only about code. Something like:
“All accounts, registrations, and credentials created for this project, including app store developer accounts, signing keys, domains, cloud hosting, and source code repositories, will be registered in the Client’s legal name, using a Client-controlled email address, and billed to the Client’s payment method. The Developer will be given access as an invited member or administrator, which the Client may revoke at any time. Any signing keys or secrets generated by the Developer will be delivered to the Client within five business days of creation.”
Have your lawyer adapt the wording. What matters is the principle: you own the account, and the developer is a guest in it. Once that’s how things are set up, handing the project to someone else means removing one person’s access, not a rescue effort.
If your project is already underway, use this list as an audit. Log into each of the five yourself. If you can’t, now is the time to fix that, while the relationship is still friendly.
How we handle it
At orithLabs, we create every account under the client’s organization from the first day: store accounts, cloud projects, repositories, and domains. We work as invited members, and signing keys and secrets are documented and handed over as they’re created. We do the same with our own apps, Crumb Count and Kompete, because an app you can’t legally update isn’t ready for production. If you’ve inherited a project where you’re not sure who owns what, a short code audit is often the quickest way to find out, and we’re happy to help you work through it. Once everything is back in your name, keeping the app updated and running is what our maintenance and support work covers.