Tolaron
A smartphone in a navy case lying face down beside a set of brass keys with a coral tag and a sheet of pencil sketches

Who owns your app? What to check before you sign

By Zdeněk Dolák, Founder6 min read

Store accounts, source code, signing keys, services and the contract: what must be in your company's name so you can keep releasing your app.

An app is only yours if you can keep releasing it without the people who built it. That depends on five things: the store accounts are registered to your company, the source code and build setup sit in a repository you control, the keys and certificates can be recovered from your accounts, the services the app relies on are billed to you, and the contract says what you may do with the code. Check all five before you sign with any supplier, us included. If an app is already live, check them while the relationship is still good.

Most companies find out they don't own their app when they want to change supplier. The code is in the agency's repository, the app is listed under the agency's developer account, and nobody on the company's side has ever logged in to either. None of this is usually bad faith. It's what happens when nobody asks early.

Store accounts in your company's name

The Apple Developer Program account and the Google Play Console account are the most important items on this list. Whoever holds them controls the store listing, the releases and the reviews.

Both stores let an organisation enrol in its own name. Both ask for a D-U-N-S number to verify the company, so apply for one early if you don't have it, because it can take a while to be issued. Once the accounts exist, you can invite the supplier as a team member with a role that lets them build and submit releases. They don't need to own the account.

If the app is already published under the supplier's account, it can be moved:

  • Apple supports an app transfer between developer accounts. The app keeps its bundle ID, ratings and reviews, and existing users keep getting updates. Some things stay behind or have to be set up again. Apple lists push notification (APNs) certificates, the Apple Pay merchant ID and sales data after the transfer among them.
  • Google Play supports a transfer to another developer account. Users, ratings, reviews and statistics go with the app, while earnings reports and test tracks stay behind.

Both processes have conditions, so read the current requirements before you plan the date. Neither is something to do in the week of a dispute.

Source code and a build you can repeat

Having the source code is not the same as being able to release it. Ask for:

  • A repository in your organisation's GitHub, GitLab or Bitbucket account, with the supplier as a member rather than the owner.
  • The full history, not a zip file of the latest version.
  • Written build and release steps that someone outside the original team can follow.
  • The build pipeline configuration, if releases are automated, and access to the build service it runs on.
  • A list of every environment variable and secret the app needs, with where each one is stored. The values themselves belong in a secrets store you control, not in the repository.

A good test is simple: can a developer who has never seen the project produce a release build from the repository and the written steps alone? If not, something is still living on someone's laptop.

Signing keys and certificates

Stores accept only updates signed by the right keys. Losing them used to mean losing the app.

  • Android. With Play App Signing, which Google Play requires for new apps, Google holds the key that signs what users install. The developer keeps a separate upload key. If the upload key is lost, the account owner can ask Google to reset it. So the account matters more than the file, provided the account is yours.
  • Older Android apps may have been set up before Play App Signing existed, with the signing key kept by the developer. Ask whether that's the case and where the key is.
  • iOS. Signing certificates and provisioning profiles are issued from the Apple Developer account. Whoever controls the account can create new ones. The key used to send push notifications also comes from that account.

The services the app depends on

A typical app uses a handful of outside services: push notifications (often Firebase), crash reporting, analytics, maps, payments, email or SMS. Each has an account, an owner and an invoice.

For each one, find out who owns the account and who pays for it. If the supplier's company card is on the invoice, the service stops when that arrangement does. It helps to keep a one-page register of these services, with the owner, the billing contact and where the credentials are kept.

Domains count too. Links that open the app directly depend on files served from a web domain. If that domain belongs to the supplier, those links break when it lapses.

What the contract says about the code

Under Czech copyright law, the author's economic rights can't be transferred (§ 26 of Act No. 121/2000 Coll.). What a company receives is the right to exercise them or a licence. For software made to order, the law's default favours the client: the client is treated as the employer and exercises the rights (§ 58(7)). That default applies only where the contract doesn't agree otherwise, and it covers the supplier's own work, not third-party or open-source components, which keep their own licences.

So don't rely on defaults. The contract should say plainly that:

  • You may use, modify and develop the app further, including with another supplier.
  • The source code, history and build documentation are handed over, and when.
  • Which components the supplier brings from earlier work, and on what terms you may keep using them.
  • Store accounts, repositories and service accounts are opened in your name, or when they will move to you.

This is a checklist, not legal advice. Have your lawyer read the agreement.

A checklist to keep

ItemWhat to checkWhere it should live
Apple Developer accountRegistered to your company; the supplier invited as a team memberYour organisation, with at least two people from your side who can log in
Google Play Console accountRegistered to your company; the supplier has a user role, not ownershipYour organisation, with at least two people from your side who can log in
Source codeFull history in a repository you own; the supplier is a memberYour GitHub, GitLab or Bitbucket organisation
Build and releaseWritten steps a new developer can follow; access to the build serviceIn the repository and your build service account
Signing keysPlay App Signing enabled; upload key and certificates recoverable from your accountsYour store accounts and a secrets store you control
Outside servicesOwner, billing contact and credentials for push, crash reports, analytics, maps, paymentsAccounts in your name, listed in one register
Domains and linksDomains used for app links and the backend are yoursYour domain registrar
ContractRight to modify and develop further; handover of code and documentation; supplier's own componentsThe signed agreement, read by your lawyer

If you're already locked in

If some of this is in the supplier's hands today, ask for it calmly and in writing, while the work is going well. A reasonable supplier will agree. It costs them little, and it makes the relationship easier to trust.

Start with the store accounts and the repository, because everything else can be rebuilt from those. If the app has to move from the supplier's store account to yours, plan the transfer with them rather than around them. Our mobile app development page explains what we look at before taking over an existing app. For the rest of a project brief, see what to send before asking for a mobile app proposal.

Next step

If you're not sure who holds what for your app, send us a short description through the contact page: which stores it's in, who built it and what you have access to today. Please don't send passwords or keys; they aren't needed to talk it through.

Sources