Who Owns Your Mobile App Source Code? What to Check in the Contract

You are probably reading this with an app quote on your desk, or right after a falling out with your developer. In both cases, start with three quick questions:

1. Does the contract clearly assign the source code and the intellectual property rights to you?
2. Whose name is on the Apple and Google developer accounts?
3. Who holds the admin credentials for the server, the database, and the domain?

In this guide, Talha Aslan and team walk through ownership from both the technical side and the contract side. We checked the store procedures against Apple's and Google's official help pages. One important note: this article is general information, not legal advice. Have a lawyer review your contract before you sign it.

What is the difference between source code, the app binary, and IP rights?

These three ideas get mixed up all the time. However, your contract has to treat each one separately. In practice, source code is the set of files a developer writes and can edit. The app binary is the packaged file that installs on a phone. You can run it, but you cannot change it. Intellectual property (IP) is the bundle of rights to use, copy, modify, and distribute that work.

For example, if the developer hands over only the live app in the store, you have a working product. Still, the day you want a new feature, no other team can pick up the work. On the other hand, even if you receive the code as a folder, your right to copy and change it can stay unclear without a written assignment.

So a safe contract covers three things together. First, the physical delivery of the code. Second, a written transfer of rights. Third, the access you need to rebuild and publish the app yourself. If one of these is missing, your ownership exists only on paper.

If the contract says nothing, who keeps the app source code?

When the contract is silent, the rights in the app source code often stay with whoever wrote it. In many legal systems, including the United States, a commissioned work by an independent contractor does not automatically belong to the client. In general, the client needs a signed, written assignment. A vague line such as "the app will be yours" may not be enough.

In practice, this creates a quiet problem. The business keeps using the app. Then, when it wants to hand the code to a new team, the original developer objects. Some developers also resell the same codebase to other clients and do not see a conflict.

Therefore, ask for a clear clause that assigns all rights in the work, including the source code, worldwide and without time limits. List each right that moves to you. Laws and their interpretation vary by country and change over time, so confirm the details with a lawyer in your jurisdiction. Here we only describe the general picture.

Does it matter whether an employee, a freelancer, or an agency writes the code?

Yes, because the default position changes with the author. In many jurisdictions, work an employee creates within the scope of the job belongs to the employer by default. A freelancer or an agency, however, is not your employee. As a result, you have to build the transfer into the contract yourself.

That said, the last row is easy to miss. If the agency outsourced part of the work and never secured those rights, it cannot pass full rights to you. That is why we recommend a subcontractor warranty in every app contract.

Which rights should the assignment clause list one by one?

Do not settle for a single general sentence. Instead, ask for a clause that names each right. We suggest our clients look for at least the following:

• The right to modify, adapt, and create new versions of the code.
• The right to copy the code and the app.
• Distribution rights, so you can sell the app through app stores.
• The right to make the app available to users over the internet.
• A transfer with no limits on time, territory, or number of copies.
• The right to assign or license these rights to third parties later.

In addition, list the assets the transfer covers: source code, database schema, interface design files, icons and images, copy, and technical documentation. For instance, if a separate designer created the screens, the design files need their own assignment too.

Finally, state when the transfer happens. Some contracts tie it to the final payment, while others tie it to each delivery milestone. Either option can work. Just do not leave the timing open.

License or assignment: which one should you ask for?

An assignment means the rights move to you. A license means the developer keeps the rights and lets you use the work. If the app sits at the center of your business, an assignment is usually the safer choice. It lets you switch developers, sell the app, or prove ownership when you raise money.

That said, a license is not always a bad deal. If you rent a ready-made booking or ordering platform for a monthly fee, nobody writes custom code for you anyway. In that case, the license terms matter most: the term, what happens to your data when it ends, and any cap on price increases.

What about a mixed model? Many agencies license their shared framework and assign the parts they write only for you. This is a fair approach, as long as the contract lists which files fall into which group. Otherwise, any module can turn into a dispute with a simple "that part is our framework."

Ask about this split whenever you compare offers. The questions in our guide to evaluating a mobile app quote make that comparison much easier.

What happens to open source libraries and third-party components?

In practice, no modern app starts from a blank page. Developers rely on open source libraries and commercial components for login, maps, charts, and payments. Nobody can assign those rights to you, because the developer does not own them either. What you get is the right to use them under their own license terms.

So add a clause that says the developer will deliver a list of all third-party components and their license types. Some open source licenses include terms that may require you to publish your own code under certain conditions. If the team plans to use such a component, ask them to get your approval first.

Paid components also need the same care. If the agency bought the license in its own name, you may lose access when the relationship ends. Therefore, require that paid licenses go directly into your company's name. You will see a similar logic in the native vs cross-platform decision, since your technology choice also shapes which components you depend on.

Whose name should be on the Apple and Google developer accounts?

The developer accounts should belong to the person or organization that publishes the app, which means you. On its Apple Developer Program enrollment page, Apple explains that an individual's name appears as the seller name for individual enrollments. For organizations, the organization's name appears instead. Apple also asks organizations for a D-U-N-S Number.

Likewise, Google follows a similar split. The Play Console account type page tells you to choose an organization account if you create the account for an organization or business. It also requires a D-U-N-S number for that account type. If enrollment stalls, our Apple Developer enrollment and D-U-N-S guide can help.

Publishing from the agency's own account looks convenient at first. In that setup, however, the store shows the agency as the seller, and reviews and download stats pile up in the agency's account. The better route is to open the accounts in your name and add the agency as a user. Both stores let the account owner invite team members and assign roles.

Why should you never hand over the account holder role?

First, note that every Apple membership has one Account Holder. According to Apple's roles documentation, this role accepts legal agreements, renews the membership, and adds the first Admins. On Google Play, the account owner is the first registered account. It has full access to Play Console and is the only one who can link a payments profile to sell paid apps.

In short, this role is the key to your app. If you leave it with the agency, the app may be legally yours while someone else controls it in practice. Example scenario: the renewal date arrives, the agency misses it, and the app drops out of the store. You cannot step in.

Instead, set things up like this:

1. Open the account in your company's name with a company email address.
2. Keep the account holder role with someone inside your business.
3. Give the development team only the access it needs for the job.
4. Review and remove access when the project ends or the team changes.

This is the same setup we recommend for social media and ad accounts. For the bigger picture, see our digital asset management plan.

How do you move an app the agency published from its own account?

Both stores let you move an app from one developer account to another, so you do not need to delete and republish it. According to Apple's app transfer overview, the Account Holder of the transferring membership starts the transfer. Then the receiving Account Holder accepts it. The app keeps its ratings, reviews, and Bundle ID, and users keep getting updates.

Apple's transfer criteria page also lists conditions. For example, the app must have at least one version that was live on the App Store. It also cannot sit in review at the time. In addition, both parties must have accepted the latest paid and free agreements.

On the Google side, the Play Console app transfer page describes the process. The original owner submits the request, and the target owner approves it. Users, download statistics, ratings, and reviews move to the target account. However, bulk export and earnings reports stay behind, so download them first. Test groups also need to be set up again.

Add a clause that says the agency will transfer any app it published in its own account to your account on request, within a reasonable time.

Why do signing keys and certificates matter so much?

App stores use digital signatures to confirm that an update really comes from the app's owner. If you lose the signing keys, shipping updates can become difficult. As a result, keys belong on the delivery list right next to the source code.

Google's Play App Signing page separates two keys. The developer holds the upload key and signs the app bundle with it before upload. Google holds the app signing key and signs the APKs that reach users. If you lose the upload key, you can request a reset in Play Console. If you manage your own app signing key and lose it, though, the page says it cannot be reset.

On Apple's side, certificates and profiles live under the developer account. If the account is in your name, a new team can recreate them with its own access. So ask for the upload key, its passwords, and a written note on which certificate lives in which account. Share passwords through a secure password manager, not by email.

Who should control the server, the database, and the API?

Most business apps show their face on the phone, but their brain lives on a server instead. Specifically, user accounts, orders, bookings, and content all sit in a database. The app reaches that data through an API, the interface apps use to exchange data. Even with the app source code in hand, the app stops working if you lose server access.

Because of that, make these points explicit in the contract:

• Whose name and payment method the server or cloud account uses.
• Who holds admin access to the database and its regular backups.
• That the API (backend) source code is part of the transfer too.
• That the domain and email accounts belong to your business.
• Where personal data lives and who can access it.

The last point also ties into legal duties. If you process user data, you carry responsibility for it, and we cover this in our mobile app privacy compliance guide. For the same problem on websites, read how to take back your website and domain from an agency.

Whose name should third-party service accounts use?

An app is more than a store listing and a server. Analytics, crash reports, push notifications, maps, email delivery, and payments usually run on separate services. Each one also means an account, a bill, and a key.

Here is a pattern we see often. The developer creates these services in a personal account during the build and leaves them there after launch. Example scenario: the developer's card expires, the notification service stops, and your users no longer get order alerts. Even finding the cause can take days.

So add a clause that says the developer will open every third-party account in your company's name or hand it over at delivery. At handover, ask for a list that shows each service, its owner, and its billing details. Google's app transfer page also notes that integrations such as Analytics permissions and Cloud links do not move with the app automatically. You have to update them yourself.

What should an app source code delivery list include?

In practice, the delivery list is the most concrete part of the contract. We use the table below in our own projects, and you can attach it to your contract as an appendix.

Do not underestimate the documentation row. Even with the code in hand, a new team needs a long time to understand a project with no written build steps, and you pay for that time.

When and how should you receive the app source code?

Getting the app source code as one archive file at the end of the project is the weakest option. It is hard to confirm that the archive is the latest version, and the change history disappears. Instead, ask for the code to live in a repository under your name from day one.

That way, you see every change as it happens. Even if the project stops halfway, you own everything written up to that point. Also, because you added the developer as a user, you can remove access with a single click when the work ends.

One more detail about the repository: you should own it, and the developer should be the invited user. If the repository sits in the developer's account and you are only a guest, your access can vanish in a moment. In other words, check the ownership setting of the repository, not just your access.

Then verify the delivery with a simple test. Ask an independent developer to build the app from scratch using only the delivered documentation. If the build works and the result behaves like the store version, the delivery is real. We suggest running this check before the final payment.

Also write the delivery date into the contract, along with what happens if it slips. A phrase such as "we deliver when the project is done" does not help when the parties disagree on what "done" means.

How should the contract define maintenance and bug fix periods?

The first weeks after launch are when real users push the app hard for the first time. For that reason, define a warranty period in the contract. During this window, the developer should fix bugs within the delivered scope at no extra cost.

After the warranty, sign a separate maintenance agreement. Put the following in writing:

• Severity levels for bugs (app down, feature broken, cosmetic issue).
• First response and resolution times for each level.
• Whether updates for new OS versions and store rule changes are in scope.
• That new feature requests count as new work, not maintenance.
• A fresh handover of current code and access when maintenance ends.

Required store updates make up a large share of any maintenance budget. We explain how this affects cost in what determines mobile app development cost. We do not quote fixed times or prices here, because we look at every project on its own scope.

How do you link the payment schedule to the rights transfer?

For the developer, the biggest risk is delivering the work and not getting paid. For the business, the biggest risk is paying and not getting the code. One method solves both worries at once: split payment into milestones and receive the code for each milestone as you pay for it.

Example scenario: you divide the project into four stages, namely design, core features, full features, and launch. At the end of each stage, the developer pushes the code to your repository. Then you review it and release that stage's payment. As a result, neither side carries a large risk.

Contracts that tie the rights transfer to the final payment are also common, and that can be a fair request from the developer. Even then, keep the code in your repository from the start. In other words, the legal transfer may happen at the end, but you hold the physical code throughout.

In addition, match the payment schedule to the items on your delivery list. A sentence such as "the client makes the final payment once the delivery list is complete" makes every item on the list binding.

What do confidentiality, non-compete, and reuse clauses protect?

Above all, your app reflects part of your business model: pricing logic, promotions, or the way your operations flow. A confidentiality clause stops the developer from sharing what they learn during the project. Make sure it stays in force after the contract ends.

Reuse is a more delicate topic. Developers naturally carry general know-how into other projects, and banning that is not realistic. On the other hand, it is fair to stop them from selling the business logic, screens, and content they built for you to a competitor.

A balanced clause might read like this: general code snippets and know-how stay free to use, while your custom business logic, design, and content become yours and the developer cannot hand them to others. If you want a non-compete, limit it to a reasonable period and industry. Because enforceability varies by country, get your lawyer's view.

What should you do if the project stalls or you part ways with the developer?

Still, not every project ends as planned. The developer may move on, the agency may close, or communication may break down. If that happens, stay calm and work through these steps in order:

1. Gather your contract and messages in one folder, and mark the transfer and delivery clauses.
2. Check whose name is on the store accounts, the server, and the domain.
3. In the accounts that are yours, review every authorized user and change passwords.
4. Ask the developer in writing for the missing delivery items, with a reasonable deadline.
5. If the app sits in the agency's account, ask them to start the official transfer process described above.
6. If you get no answer, talk to a lawyer about your legal options.

One warning: do not trust anyone who offers to "recover" your accounts by accessing them without permission. Getting into someone else's account or misleading store support with fake documents carries legal risk and can put your developer account at risk too. The stores' official transfer path and your contract are the strongest tools you have.

How can you check the contract before you sign?

We gathered all of these points into one checklist. If you can say "yes" to every line before signing, you have closed most of the basic risks.

• The contract assigns all rights, including the source code, and lists them one by one.
• The transfer has no limits on time, territory, or number of copies.
• If the agency uses a shared framework, the contract lists the files it licenses.
• The agency confirms it holds all rights from its subcontractors.
• Your company will own the Apple and Google developer accounts.
• The server, database, domain, and third-party accounts belong to your business.
• From day one, the code lives in your repository.
• The delivery list is an appendix to the contract.
• Both the warranty period and the maintenance terms are defined.
• Payments follow delivery milestones.
• The confidentiality clause survives the end of the contract.

When you use the list, write the matching contract clause number next to each line. That way, any gap shows up at a glance. You can also send the list to the developer in advance. A serious team answers these questions easily and adjusts the draft. An offer that dodges a line, however, sends you a clear warning sign.

Treat this list as a starting point. Your project may need extra clauses, so the healthiest path is to have a lawyer review the final text.

How do Talha Aslan and team handle ownership in app projects?

In our mobile app development projects, we raise the ownership question in the very first meeting. We build your app and launch it in the stores for you. Still, we open the developer accounts, the server, and the code repository in your name from the start. We work inside those accounts with only the access we need.

Our proposal shows the delivery list, the warranty period, and the maintenance options as separate sections. That way, you see which item moves to you and when, before you sign anything. If part of the project uses a shared framework of ours, we say so clearly.

If your app idea is ready, or you have a half-finished project on your hands, let's look at it together. Request a quote through our mobile app development service page, and we will prepare the scope and the delivery list for your project.