Who Should Own Your App's Apple and Google Developer Accounts?

Months after a mobile app goes live, a business owner calls the agency that built it to ask for an update, and discovers the agency has closed, gone quiet, or wants to charge for access to something the owner assumed they already owned: the account the app is actually published under. This is not a rare story. A mobile app is not just code; it is also a listing on Apple's App Store and Google Play, sitting inside a developer account, and whoever controls that account controls whether the app can be updated, who it is published as, and whether it stays listed at all. This guide covers who should hold that account, what to ask for before a build starts, and what to do if the wrong person already holds it.

What a developer account actually controls

An Apple Developer Program account and a Google Play developer account are not the same thing as the app's code. The code is what runs on the phone; the account is the administrative identity the app is published under on each store. Whoever owns the account controls:

• The published listing itself. The app's page on the store, including the developer or publisher name shown to anyone who looks it up.
• Every future update. New versions, bug fixes and security patches can only be submitted through the account the app is tied to.
• Store communications. Policy warnings, required changes, and account-level notices from Apple or Google go to whoever holds the account, not automatically to the business whose name is on the app.
• The decision to remove or suspend the app. Only the account holder can take the app down, or is responsible when the store does.

None of this is the same question as who owns the source code. That is a separate, equally important matter covered in who owns the source code of your custom business system. A business can own its code outright and still be unable to update its own app, if the account it is published under belongs to someone else.

The risk when an agency holds the account instead of you

Paying an agency to build and publish a mobile app is normal. The risk is specifically in whose account it gets published under. If that account belongs to the agency rather than the business, the business is, in effect, a guest on its own app.

What this means in practice, if the relationship with that agency ends badly, goes quiet, or simply changes:

• No one at the business can push an update. A bug fix, a required security patch, or a seasonal change all wait on someone who may no longer be answering.
• The business cannot respond to a store policy issue. If Apple or Google flags something that needs a response, the account holder is who gets asked, and who must act.
• The app can disappear from the store. If the agency's account is closed, suspended, or simply stops being renewed, every app under it, including yours, goes down with it.
• The listed developer name may not be the business's own. Customers checking who published the app see the agency's name, not the business's.

None of this requires bad faith. An agency that quietly shuts down, gets acquired, or simply forgets to hand over an account creates the same outcome as one that deliberately withholds it. The practical lesson is the same either way: this is worth settling before development starts, not after the app is already live and something has gone wrong.

Account ownership and collaborator access are different things

The useful distinction is between who owns the account and who is allowed to work inside it. Both Apple and Google let an account owner add other people with roles scoped to what they actually need to do, without handing over ownership of the account itself.

This is the arrangement that actually protects a business: the account is registered in the business's own name, and whoever builds the app, whether an agency, a freelancer or an in-house developer, is added as a collaborator with exactly the access the work requires. If you are weighing which of those three should build the app in the first place, hiring a freelancer, an in-house developer or a development company covers that decision; this guide assumes the choice is made and focuses on the account question that follows it.

What to ask for before a mobile app build starts

Settle this at the same stage you settle price and scope, not after the app is submitted to a store.

1. Ask whose account the app will be published under. The answer should be your business's own Apple Developer Program and Google Play developer accounts, registered in your business's name.
2. If the accounts do not exist yet, create them yourself, or have your business register them. Each store's registration process is designed for the account holder to complete directly; a developer can guide you through it, but the registration itself should be under your business.
3. Confirm you personally hold the account's own login, or at minimum an admin role. An admin role lets you manage who else has access, which matters if the current developer relationship ever needs to change.
4. Add the developer as a collaborator with a scoped role, rather than handing over the account's own credentials. This is the normal way both stores expect accounts to be shared.
5. Get the account arrangement confirmed in writing, alongside the usual scope and price terms, so there is no ambiguity to resolve later if the relationship changes.
6. Ask what happens to the listing if the relationship ends. A written answer now is worth far more than a verbal assurance once there is a disagreement to have.

None of this is unusual to ask for, and a developer who has done this before should expect the question. It is a smaller, calmer conversation to have before a contract is signed than after an app has gone missing from a store.

If your app is already live under someone else's account

This situation is recoverable, but it is slower and less certain than starting correctly, so it is worth fixing even if nothing has gone wrong yet.

• Both accounts need to be active and in good standing. A transfer moves an app from one developer account to another, and both ends of that move have to be in working order.
• The current holder has to cooperate. A transfer is not something the business can force through alone; it needs the account that currently holds the app to agree and act.
• Reviews typically carry over; some reports and data do not. Ratings and reviews generally move with the app, but things like historical earnings or usage reports are often tied to the account they were generated in, not the app itself, so back up what you can before a transfer.
• Expect a review period, not an instant switch. Each store checks a transfer before completing it, which adds time the business should plan around rather than be caught out by.

If the current relationship with whoever holds the account is still workable, the easiest path is simply asking for the transfer now, in writing, rather than waiting for a reason that forces the question. The guidance above under "what to ask for" applies just as well retroactively as it does before a build starts.

Why this question is specific to mobile apps

This entire risk is a feature of how app stores work, not of custom software in general. A web app, the kind that runs in a browser rather than being installed from a store, has no developer account to worry about: it lives on a domain and a hosting account the business already controls, the same as any website. Nothing about accessing it depends on Apple or Google. Web app vs mobile app: which does your business actually need covers that broader decision, and it is worth revisiting if a mobile app's account complexity is itself a reason to question whether a mobile app is the right build in the first place. For a business that has not yet decided whether it needs one, signs it is time to add a mobile app to your existing web app sets out when the jump actually pays off.

Mobile apps carry this requirement because the stores themselves were built around a single accountable publisher per app, for security review, policy enforcement and billing. That design choice is reasonable for Apple and Google; it just means the business commissioning the app has one more thing to own than it would with a website or a web app, and one more thing worth getting right from the first conversation with a developer.

A short scenario

A café chain hires an agency to build a loyalty app for iOS and Android. The agency quotes a fair price, delivers on time, and the app works well. Eighteen months later, the café wants a new feature added and asks the agency for a quote. The agency has moved on to other work and is slow to respond. The café owner tries to find another developer to make the change instead — and discovers the app is published under the original agency's own Apple and Google accounts, not the café's. No one at the business can submit the update, respond to a store notice, or even confirm who currently has access. The code itself might be perfectly usable; the account it depends on is the actual blocker.

Had the original contract simply named the café's own developer accounts as the publishing accounts, with the agency added as a collaborator, the same change eighteen months later would have been a normal conversation with any developer willing to do the work, not a search for someone who still has the login.

What this costs

Each store charges the account holder its own registration fee to open a developer account, separate entirely from what a developer charges to build the app. These fees are paid by the business directly to Apple or Google, not bundled into a development quote. How much does a custom mobile app cost in Malaysia covers this cost split in more detail, alongside the cost drivers behind the development work itself. Gotka's App & System Development service builds mobile apps from an indicative RM15,000, confirmed by written quote once the scope is understood; store registration fees sit outside that quote and are the business's own, regardless of who builds the app.

Common mistakes

• Never asking whose account the app will sit under. Silence on this question usually means the developer's own account is the default.
• Assuming owning the code means owning the listing. They are governed separately; confirm both.
• Handing over full account credentials instead of adding a collaborator role. This reverses who actually controls the account.
• Treating account ownership as a detail to sort out later. It is far easier to set up correctly at the start than to untangle after a falling-out.
• Assuming a transfer is instant if something does go wrong. It requires a cooperative counterpart and a review period, so it is a recovery option, not a safety net to rely on.
• Not getting the arrangement in writing. A verbal understanding about who controls an account is not something you can act on months later.

Where Gotka Technologies fits

Gotka's App & System Development service builds web apps, business systems and mobile apps, with mobile apps indicative from RM15,000, confirmed by a written quote once the scope is understood. On a mobile app build, that includes publishing under a developer account registered in the client's own business name, with Gotka added as a collaborator for the work rather than holding the account itself — the arrangement this guide recommends asking any developer for. A mobile app that depends on a backend also needs somewhere reliable for that backend to run, which is where Gotka's Cloud Hosting comes in.

Key terms used in this guide

• Developer account: the administrative account with Apple or Google that an app is published under, separate from the app's own code.
• Apple Developer Program: the paid account required to publish an app on Apple's App Store.
• Google Play developer account: the account required to publish an app on Google Play for Android.
• Account owner: the party whose name the developer account is registered under, with full control over it.
• Collaborator role: a scoped level of access, such as developer or admin, that lets someone work inside an account without owning it.
• Publisher name: the developer or company name shown publicly on an app's store listing.
• App transfer: the process of moving an app's listing from one developer account to another.