Can I get the source code of my app?

The honest answer is: it depends on a piece of paper

People ask this question with a sinking feeling, usually after a falling out with a developer or when considering moving to a new one. They have paid for an app, it is running on their customers' phones, and they have realised that they have never actually seen the code. They want to know whether they own it, and whether they can get it.

The short answer is that you usually can, but only if your agreement says you can. Nothing about the app being on your customers' phones, or about your having paid for it, automatically gives you the code. The code is a creative work, and the person who creates a creative work generally holds the rights unless they transfer them in writing. That is why the answer is in the paper and not in the app.

Intellectual property in plain words

Software code is protected as a copyright work. The default rule is that the author owns it. If a developer writes code for you as an independent contractor, they are the author. If they are your employee, and the code is written in the course of their employment, the employer is generally the first owner. The difference between contractor and employee is therefore very important.

To move ownership from a contractor to you, there has to be a written assignment, signed by the person transferring the rights. A simple clause in the project agreement that says 'all rights in the work are assigned to the client on payment in full' does this. Without it, the most you may have is a licence to use what was built, and licences can be narrow.

These are general principles, and the details depend on the facts and on the law. For any contract that matters, have a lawyer read it. It is among the cheapest professional help you can buy relative to what is at stake.

How the common arrangements work out

In the best case, you commissioned a custom build under a written agreement that assigns the code to you on payment, and the repository is on your account. You have the code, and you can take it anywhere. Ask for everything: the repository, the build instructions, the credentials and a handover document.

If you commissioned custom work with no written agreement, the position is uncertain and tends to favour the developer. You may have an implied licence to use the app, but not necessarily the right to modify it or to give it to another developer. The right course is to ask for a written assignment now, while the relationship is still working. The developer may well agree, particularly if you have paid in full.

If your app was built by an agency on its own platform or a reusable base, you may receive only a licence to the final product, with the underlying platform remaining theirs. That is not necessarily wrong, and plenty of arrangements work this way. But you should know it, and you should know what happens if the agency closes or raises its price.

If you use a white-label or SaaS product, you are renting. You may be able to export your data, but you will not get the code, because it was never yours to receive.

What to ask for in writing, before you start

1. That ownership of all code, designs and documentation transfers to me on payment.
2. That the code repository is created under my account from the start.
3. That the app store and hosting accounts are registered in my name.
4. A list of any third-party or reusable components, with their licences.
5. A handover of source, build instructions and credentials at the end.

These five points take a page to write and settle the whole question. They are easy to agree at the start of a project, when everyone is on good terms, and very hard to negotiate afterwards.

Open-source and third-party code

Almost every modern app includes code written by other people: libraries for navigation, networking, charts and a hundred other things, most of them open source. That is normal and sensible. It does not stop you owning the code the developer wrote. But it means you do not own all of it in the sense of being free to do anything with it.

Open-source libraries come with licences, some of which impose conditions, for example requiring that you credit the authors or share changes in particular circumstances. A responsible developer keeps a list and tells you about anything unusual. For most apps the licences are permissive and cause no trouble.

What you want from the handover is that list, so that you or a future developer or a lawyer can see what is in the product, and under what terms.

If you are already in a difficult situation

If you have paid and the developer is not responsive or is withholding the code, start by gathering what you have: the agreement if any, messages, invoices, payment records. These establish what was agreed and what you paid.

Then ask clearly and politely, in writing, for the source code and what you need to run and build it, referring to what was agreed. Most disputes are resolved at this stage, because most developers do not want a dispute either.

If that fails, take legal advice. A lawyer can tell you what your position is, write a formal notice, and explain the options. The position depends on the facts, and it is much better to understand it before escalating.

A middle path when trust is thin: escrow and staged handover

Sometimes a buyer and a developer are both nervous. The buyer fears paying and never receiving the code, and the developer fears handing over the code and never being paid. There are simple structures that address both. One is a staged handover tied to the payment milestones: the buyer pays each milestone, and the developer pushes the code at that point to a repository under the buyer's account.

Another is a third-party arrangement in which the source is deposited with an independent holder and released on agreed conditions, such as the developer closing the business or failing to provide support. It is less common for small projects and is worth considering for larger or more critical software.

In practice the simplest and strongest structure is the first. If the repository is under your account from day one and the developer has access as a collaborator, there is nothing to hand over at the end, because you already have it.

What 'the source code' actually includes

People often ask for the source code and receive a folder that does not let them rebuild the app. The source code is only one part of what you need. A complete handover also includes the build configuration that turns the code into an installable app, the signing keys or certificates that identify it to the app stores, the list of third-party libraries and their versions, the credentials or access to any services the app talks to, and the documentation that explains how it all fits together.

Without the signing keys, you may be able to publish a new app but not an update to your existing one, because the stores treat them as different. Without the service credentials, the code runs but cannot reach its server. Ask for a test: have another developer, or the original one under your supervision, build the app from the handed-over material on a clean machine. If it builds and runs, the handover is complete.

Keeping your position safe from now on

Whatever the history, put yourself in a safe position going forward. Have the repository moved to your own account, with the developer as a collaborator. Make sure you have the keys and credentials to every service the app depends on. Take a copy of everything and store it where you control it.

Schedule a regular check, perhaps every quarter, to confirm that you can still build and release the app yourself or with another developer. It is the kind of check that feels unnecessary right up until the day it is vital.