Who Owns the Source Code After App Development?

Short answer

You do not automatically own your app’s source code just because you paid for it. Under United States copyright law, the person who writes the code owns the copyright unless a written agreement assigns those rights to you. To genuinely own your app you need three things in writing: a signed intellectual property assignment, delivery of the actual source code, and your own Apple Developer account in your company’s name. Sort all three before work starts.

Why paying for an app does not mean you own it

This surprises almost every first-time app owner. You commission an app, you pay the invoices, and you reasonably assume the result is yours. Legally, that assumption is often wrong. Copyright in software attaches to whoever creates it the moment it is written, and paying someone to do work does not by itself move that copyright to you.

The United States Copyright Office is explicit about this. Its guidance on works made for hire explains that when work is created by an independent contractor, rather than an employee acting within their job, the contractor is the author and owner of the copyright unless there is a signed written agreement stating otherwise. An external developer or agency is an independent contractor. So without the right paperwork, they, not you, own the code they wrote for you. Payment settles the bill; it does not settle ownership.

This is not usually about anyone acting in bad faith. Plenty of honest developers simply never raise the question, and plenty of clients never think to ask. The gap only becomes painful later, when you want to change developers, sell the company, or raise money and an investor asks to see proof that you own your core asset. At that point, missing paperwork is expensive to fix and sometimes impossible.

The three things that make an app truly yours

Owning your app is not a single document. It is three separate things, and you need all of them. Missing any one leaves you dependent on someone else.

What you need	What it covers	What goes wrong without it
IP assignment clause	Legal ownership of code and designs	The developer keeps copyright; you licensed it at best
Source code delivery	The actual code, in a repo you control	You cannot change teams or rebuild the app
Your own Apple Developer account	The App Store listing and updates	The agency controls your store presence

The first is legal, the second is practical, and the third is about distribution. A contract can assign you the copyright, but if you never receive the code, ownership is theoretical. You can receive the code, but if the app is published under the agency’s Apple account, they still control what users download. Real ownership means the rights, the files, and the account all sit with you.

The IP assignment clause: read this before you sign

The single most important term in a development contract is the intellectual property assignment clause. It is the sentence, or paragraph, that transfers ownership of everything produced, the source code, the designs, the assets, to you. A well-drafted clause assigns all intellectual property in the deliverables to your company, and it usually does so on final payment.

Assignment on final payment is normal and reasonable. It means the developer holds ownership as a form of security until you have paid in full, and then it passes to you completely. What you are checking for is that ownership passes at all, and that it passes to you rather than being merely licensed. A licence lets you use the app; assignment makes it yours. Those are very different, and vague contracts sometimes blur them on purpose.

Watch for a few specific things. Ownership should cover the custom code written for you, not third-party open-source components, which keep their own licences and cannot be assigned by anyone. The clause should name your company as the owner. And it should not carve out large exceptions that let the developer reuse your core, distinctive work elsewhere. Generic building blocks being reused is fine and normal; your unique product being reused is not.

If you are worried about someone taking your idea before the contract is signed, that is what a non-disclosure agreement is for. An NDA protects the confidential information you share during discussions, while the IP assignment protects the work once it is built. They solve different problems, and a serious project usually uses both. That said, ideas themselves are hard to protect; execution is what has value, which is exactly why owning the built code matters so much.

Getting the source code in your hands

Legal ownership is only half the story. You also need the actual source code, and you need it in a form you can use without the original developer. The clean way to do this is a code repository, such as a private Git repository, that belongs to your company from day one. The developer works in your repository, and when the project ends, you simply remove their access. Nothing has to be handed over at the end because it was always yours.

That is the standard we hold ourselves to, and it is worth asking any developer whether they work this way. When the source lives in the client’s own repository throughout, ownership is never in doubt and handover is not a dramatic event. When it lives only on the developer’s machines or in their account, you are trusting them to give it to you later, and later is when disputes happen.

A complete handover is more than a copy of the code. Use this checklist to confirm you have received everything needed to run the app without the people who built it.

Handover item	What it is	Why you need it
Source code repository	The full code in a repo you control	Rebuild and switch teams on your own
Signed IP assignment	Legal transfer of copyright to your company	Proof of ownership for a sale or raise
Apple Developer account	Your own account in your company name	Ship updates and control the listing
Design files	The editable UI and UX source files	Continue the design without redoing it
Credentials and keys	Signing keys, API keys, and server logins	Deploy and operate the app in production
Build documentation	Steps to build, run, and deploy the app	Onboard a new developer quickly

Alongside the code, a proper handover includes the things needed to actually run and rebuild the app: the design files, the credentials and keys, any backend configuration, and documentation explaining how the pieces fit together. A codebase with no way to build or deploy it is not full ownership. If you want a sense of what belongs in a clean handover, our guide on what to check before you hire an iOS app developer covers the questions to ask up front.

Owning the Apple Developer account

The third piece is the one people forget. Your app is distributed through the App Store, and the App Store listing lives inside an Apple Developer account. If your agency enrolls that account in their own name and publishes your app there, they control your store presence even if you own the code. There is also a risk you cannot contract away: Apple terminated around 193,000 developer accounts over fraud concerns in 2025, per its May 2026 fraud report, and when an account goes down, every app inside it goes with it. Your app should not share a fate with whatever else your vendor publishes.

Enroll your own Apple Developer Program membership in your company’s legal name, and have developers added to it rather than the other way round. This keeps the app under your organization, preserves your reviews and ratings, and lets you change who works on the app without migrating anything. Apple does support moving an app between accounts through its app transfer process, which is a useful safety net, but transfers have conditions and are far more friction than simply owning the right account from the start.

Controlling the account also matters for updates. When your app needs a fix after an iOS release, whoever holds the account is the one who can ship the update. If that is not you, your ability to maintain your own product depends on someone else’s cooperation. For more on what that ongoing work involves, see our piece on app maintenance costs after launch.

When these concerns matter less

Ownership is not equally critical for every project. If you are building a quick internal tool that only your staff will ever use, that you do not plan to sell or raise money against, the stakes are lower, and a simple licence to use it might be all you practically need. The full apparatus of assignment, repository ownership, and a dedicated developer account is most important when the app is a real business asset: something you will grow, maintain over years, sell, or show to investors.

The trouble is that people rarely know at the start which category they are in, and retrofitting ownership onto a project that was set up loosely is much harder than getting it right on day one. Because securing ownership costs almost nothing when you agree it up front, and a great deal when you have to unwind a bad arrangement later, the safe default is to sort it out before any code is written, even if you are not yet sure how big the app will become.

Owning your app should not be a fight. A developer who builds in your repository, assigns you the intellectual property on payment, and puts the app in your own Apple account is simply doing the job properly. That is how we work, because you should own what you paid to build. If you want to talk through your project and how ownership would be handled, book a free app idea call.