Who Actually Owns Your App? Code, Keys and Store Accounts

A founder I spoke with last year wanted to move his app to a new development team. Reasonable request — the original agency had grown, his account had been handed down twice, and velocity had quietly halved.

It took him four months and a lawyer.

The code was in the agency's GitHub organization. The App Store Connect account was registered to the agency, with his app listed under their developer name. The signing certificates were on a machine belonging to a developer who had since left. The AWS account was theirs, billed to him. And the contract said he owned "all deliverables," which sounded comprehensive right up to the moment someone had to define it.

Nobody in this story was a villain. The agency was disorganized rather than malicious, and eventually cooperative. But four months is four months, and every week of it existed because ownership had never been made concrete.

The five places ownership actually lives

1. Source code. Not "you own the deliverables" — the repository, in your organization, from the first commit. This is the difference between owning something and being handed something later. Handover at the end of a project is where context goes to die: you get the code without the history, the branch discussions, or the reasoning behind decisions that look arbitrary out of context.

2. Signing keys and certificates. The Android upload key and the iOS distribution certificates. Lose control of the Android signing key and you cannot ship updates to your existing users under that listing — this is one of the few genuinely unrecoverable mistakes in mobile. These belong in your organization's secret store, with the vendor granted access.

3. Store accounts. App Store Connect and Google Play Console registered to your company, with the vendor added as a user. If your app is listed under an agency's developer name, your reviews, ratings and install base are attached to their account, and moving is a transfer process with real failure modes.

4. Infrastructure. Cloud accounts in your name, paid by you, with the vendor granted roles. "We host it for you" is convenient exactly until it is not, and cloud migration under time pressure is where data gets lost.

5. The intangibles. Designs, design system source files, prompts, fine-tuned models, and generated assets. Watch for contract language reserving "reusable frameworks and components" to the vendor — that clause reads as administrative and turns your product into something you licence. If a framework genuinely predates your project, name it and licence it explicitly.

The clause that quietly matters most

An exit plan.

Credential transfer, environment documentation, a runbook, and a defined transition assistance period at agreed rates. Negotiate it while everyone is optimistic, because once a relationship is strained it becomes unnegotiable — and a strained relationship is exactly when you need it.

The reaction to this request tells you a lot. Good partners accept it immediately; it costs them nothing, because they intended to behave that way anyway. A vendor who resists exit planning is telling you their business model depends on you being unable to leave.

Why more of this is slipping lately

Two reasons worth naming.

Generated code has increased the volume of code produced per project, which means more of your product is code nobody on your side has ever read. Ownership without comprehension is a weaker position than it looks, which makes documentation and knowledge transfer more valuable, not less.

And infrastructure has become easier for vendors to bundle. It is genuinely simpler for an agency to spin everything up under their own accounts, and genuinely worse for you every single time.

The ten-minute check

Before signing anything, get written answers to five questions:

• Which organization will hold the repository during development?
• Who registers the App Store and Play accounts?
• Where do signing keys live, and who can access them?
• Whose name is on the cloud accounts?
• What exactly happens, step by step, if we part ways in month seven?

Every one has a correct answer, all of them are cheap to arrange at the start, and all of them are expensive to fix later.

Full guide — Canadian cost bands, delivery models, contract clauses and a 30-day selection process: Mobile App Development Company Canada: The 2026 Buyer's Guide.

Frequently Asked Questions

Does paying for an app mean I own it?

Only to the extent the contract and the accounts say so. Ownership lives in the repository, the signing keys, the store accounts, the cloud infrastructure and the intangibles — and each needs to be arranged explicitly rather than assumed.

Why does the Android signing key matter so much?

Because losing control of it means you cannot ship updates to your existing users under that listing. It is one of very few genuinely unrecoverable mistakes in mobile, which is why the key belongs in your secret store, not on a developer's laptop.

Should the app be listed under my developer account or the agency's?

Yours. If it is listed under an agency account, your reviews, ratings and install base are attached to their identity, and transferring later is a process with real failure modes.

What is a reusable-component carve-out?

Contract language reserving ownership of frameworks or components to the vendor. It can leave your product dependent on code you only licence. Name any genuinely pre-existing framework and licence it explicitly; refuse blanket carve-outs.

When should I negotiate an exit plan?

At the start, while the relationship is good. It costs nothing to a vendor who intended to behave well, and it becomes effectively unnegotiable once things go wrong — which is precisely when it is needed.

Does AI-generated code change the ownership question?

It raises the stakes on comprehension. More code is produced that nobody on your side has read, so documentation, knowledge transfer and clear assignment of generated assets matter more than they did when every line was typed by a person you could ask.