App source code ownership: who owns the code and art after a build

"You own everything" is a common promise and a vague one. Ownership is a list of specific files, rights and accounts, and a good contract names them. This is what DFY Games hands over, from the published terms for game builds and the ownership terms on the app service page:

Files without the matching accounts are only half a handover. If the App Store listing sits in the studio's developer account, you own the code but someone else controls the published product.

At DFY Games the assignment takes effect after full payment and final handover. Fixed-price game packages are paid upfront, so the trigger is the handover itself. For quoted app work, your written scope sets the payment schedule, and the assignment follows the final payment.

With any studio, look for three things in the contract: the event that triggers the transfer (payment, delivery, or both), what is assigned versus licensed, and whether the license to any pre-existing studio code is perpetual and survives if you sell the product or your company. These are the points a lawyer can check quickly, and they matter more than the word "ownership" in a sales page.

No studio can assign you rights it does not hold. Almost every app or game is built on someone else's software, and those pieces come with their own terms that bind you after launch:

• Game engines and frameworks, whose license terms apply to you as the publisher.
• SDKs for ads, analytics, crash reporting and payments, governed by each provider's terms and privacy rules.
• Fonts, which need a license that covers embedding in an app, separate from desktop or web use.
• Stock images, sound effects and music, whose licenses can limit use in advertising or require attribution.
• Open-source libraries, whose licenses range from very permissive to ones with obligations if you distribute changes.
• Anything you supply yourself: names, characters, logos and references. You confirm you have the rights.

Ask for a license inventory at handover: each third-party component, where it is used, and the license it ships under. It costs the studio little to produce and saves you from discovering a font or music license problem when you are already running ads.

The Apple Developer Program and Google Play Console accounts make you the publisher of record. At DFY Games they are opened in your name or your company's, you pay the platform fees directly, and the studio works through access you grant. The same goes for hosting and payment accounts on app projects, and for ad accounts on game launch packages, where the studio receives partner access and you keep ownership and fund the spend.

Moving a published app from one developer account to another is possible on both stores, but it is its own process with its own checks. Starting in the right account avoids it entirely.

This guide explains how handovers work in practice; it is not legal advice. Before you sign any development contract, have a lawyer in your jurisdiction review it. Useful questions to bring:

1. Is this an assignment of rights or a license, and for which deliverables?
2. What exactly triggers the transfer, and what happens if a payment is disputed?
3. Is the license to the studio's pre-existing code perpetual, worldwide and transferable with the product?
4. Who is responsible if a third-party asset turns out to be unlicensed?
5. Can the studio show the work in its portfolio, and does it need your permission?

DFY Games does not show a client's game publicly as studio work without written permission. For the wider decision of who should build your product, see template, custom build or done-for-you.