App Development Contracts: 10 Clauses to Check

An app development contract is the document that fixes scope, acceptance criteria, payment milestones, source code ownership and store responsibilities before a single line of code exists. Ten clauses decide how the project ends; the most expensive one is acceptance, because in most drafts "approval" has no definition, no deadline and no named decision-maker.

Most app disputes are not about bad faith. They happen because two parties read the same sentence differently. "Delivery on completion" means a signed build to your developer and a downloadable product in the store to you. The gap between those two readings is measured in weeks of calendar time, store review cycles and an invoice nobody planned for.

This guide walks the ten clauses of an app development contract from the client's side. For each one you get the sentence that belongs in the contract, the rule it maps to, and what happens in practice when the clause is missing. Four of them — store accounts, review rejections, platform update obligations and the device test matrix — exist only in mobile projects and appear in almost no general software template.

This is general information, not legal advice. Have a lawyer review your draft; treat the list below as preparation for that conversation.

Table of Contents

• Why an app contract differs from a website contract
• 1. Scope: an annex, not a reference to one
• 2. Acceptance criteria and the testing window
• 3. Payment milestones and what unlocks each one
• 4. Delay, liquidated damages and schedule risk
• 5. IP ownership and the source code handover
• 6. Store accounts: who owns the publishing rights
• 7. Store rejections and annual platform requirements
• 8. Warranty, maintenance and support
• 9. Data protection: your developer is a processor
• 10. Termination, exit and dispute resolution
• Red flags in a draft contract
• Frequently Asked Questions

Why an app contract differs from a website contract

An app development contract carries a risk no website contract has: a mobile app is the only software you commission whose release depends on two private companies. Neither you nor your developer controls the publish button, and the gatekeepers reject a lot: Apple reports that App Review evaluated more than 9.1 million submissions in 2025 and rejected more than 2 million of them — over 1.2 million new apps and nearly 800,000 updates. Privacy violations alone accounted for over 443,000 rejections, and copycat, spam or misleading submissions for over 371,000 (Apple Newsroom, May 2026).

When roughly one in five submissions comes back, "who fixes a rejection, how many rounds, at whose cost" is not an edge case. It is the single most likely event in your launch month, and the first rejection email is a bad moment to start negotiating.

Platform maintenance works the same way. Since 31 August 2026, Google Play requires new apps and updates to target Android 16 (API level 36), and existing apps to target Android 15 (API level 35) to stay available to users on newer OS versions; developers could request an extension only to 1 November 2026, and permanently private in-house apps sit outside the rule (Play target API requirements). On the Apple side, every build uploaded to App Store Connect has had to be built with Xcode 26 and an iOS 26 SDK since 28 April 2026 (Apple upcoming requirements).

These are not defects. They are scheduled obligations that repeat every year, and an app development contract that ignores them leaves you with a product that quietly stops being discoverable twelve months after launch.

1. Scope: an annex, not a reference to one

The most common flaw in app development contract drafts is a scope clause that points at a document nobody attached. "As described in Exhibit A" means nothing when Exhibit A does not exist or carries no signature.

Your scope annex should list:

• A screen inventory. Every screen by name: onboarding, sign-up, catalogue, cart, checkout, profile, settings. A number ends the "was that screen included" argument before it starts.
• One testable sentence per feature. Not "push notifications will work" but "a notification sent from the admin panel reaches a device with the app closed within 60 seconds".
• The platform and version matrix. Which iOS and Android versions you support, which physical devices acceptance testing runs on, whether tablets count.
• Every third-party integration. Payments, shipping, CRM, maps, analytics, push, crash reporting — each with the account owner and the party paying any licence or transaction fee named on the same line.
• Languages and content. How many locales, who writes the copy, who supplies imagery.
• Explicit exclusions. Admin panel, marketing website, store optimisation work, data migration and content entry each deserve a line that says in or out.

Scope precision protects both sides. Under a fixed-price deal the developer carries the cost of its own estimate, so an unmeasured scope pushes the team toward defending margin instead of building. Under time and materials you carry that risk, which makes a written cap and a reporting rhythm the thing to negotiate instead.

Pair the clause with a change order mechanism: anything outside the annex becomes a written quote showing days and money separately, and work starts after approval. If you are still shaping the budget behind the scope, the app cost calculator gives you a range to argue from before you sit down with a draft.

2. Acceptance criteria and the testing window

This is the clause that moves the most money, and most templates cover it in one sentence.

Acceptance is where an app development contract either protects you or fails you, because it decides three things at once: when the warranty clock starts, when the final invoice becomes due, and when the developer's liability for the delivered scope narrows to hidden defects. Leave it vague and every later argument inherits that vagueness.

Write a procedure, not an adjective:

• How delivery happens: a TestFlight build and a Play closed-testing link, release notes, and the acceptance test scenarios themselves.
• A review window: 5-10 business days, with the named people who run the tests.
• A defect taxonomy: critical (checkout fails, app crashes on launch), major (a scoped feature works incorrectly), minor (copy, spacing, iconography). Only critical and major defects block acceptance.
• A fix-and-retest loop: how many business days per fix round, and how many rounds the price covers.
• Partial acceptance: if delivery is modular, each module gets its own sign-off document.
• Deemed acceptance, with a condition. Developers reasonably want a clause that treats silence as approval. Accept it only with a fixed window, a written notice that starts it, and an exception for defects the tests could not reasonably reveal.

One more sentence pays for itself: the environment. Acceptance testing on production data, on a staging server that disappears the next week, or on a single reviewer's phone produces a sign-off you cannot defend internally. Our mobile app testing guide sets out the test levels these criteria should come from.

3. Payment milestones and what unlocks each one

In an app development contract, tie money to delivered artefacts rather than to elapsed time. A milestone that reads "60% on completion of development" invites a dispute about the word completion; one that reads "on acceptance of the beta build per clause 4" does not.

The last slice matters more than its size. Holding 10-15% until the app is actually live and the code is in your repository keeps attention on the unglamorous final stretch: store metadata, review responses, signing keys, documentation.

Three details belong in the same clause: which document triggers each invoice, the payment term in days, and the late-payment interest rate. And one asymmetry deserves a sentence of its own — if IP transfer depends on "payment in full", any billing dispute becomes an ownership dispute. Keep the transfer tied to the final milestone, and make that milestone's acceptance test objective.

4. Delay, liquidated damages and schedule risk

The schedule clause of an app development contract answers two questions: when a delay starts counting, and what it costs.

Define the baseline first. Fix the start date to a condition you control (signature plus receipt of the kick-off payment plus delivery of brand assets), then fix the milestone dates as working days from that baseline. Floating dates tied to "project start" create arguments about which email started the project.

For the consequence, liquidated damages work when they look like a genuine estimate of loss rather than a punishment. Courts in common-law jurisdictions reduce or refuse to enforce penalties that bear no relation to actual damage, and many civil-law systems let a judge cut an excessive figure directly. The structure that survives review looks like this: a modest daily rate (0.1% of the contract value per calendar day is a common benchmark), a hard cap (5-10% of contract value), and a statement that the damages are the parties' pre-estimate of loss from late delivery.

Then write the other half, the part clients forget. Client-side delay — content that never arrives, approvals that sit for two weeks, an API your own IT team has not opened, a test cycle nobody runs — extends the schedule. Without a clause listing those events and their effect, your developer absorbs delays it cannot control, and prices that risk into the next project. Add a force majeure definition here too, and say explicitly whether a third-party platform outage or an unexpected store policy change counts.

5. IP ownership and the source code handover

Receiving the source code and owning it are different things, and in an app development contract they need separate sentences.

Under US law the default sits against the client in a way that surprises people. Copyright vests initially in the author, and the employer counts as the author only for a work made for hire — which means either a work prepared by an employee within the scope of employment, or a work in one of nine specifically listed categories (contributions to collective works, motion pictures, translations, supplementary works, compilations, instructional texts, tests, answer material, atlases) under a signed written agreement. Software commissioned from an outside contractor is not on that list (17 U.S.C. §101). So ownership has to arrive by assignment, and §204(a) is strict about form: a transfer of copyright ownership "is not valid unless an instrument of conveyance, or a note or memorandum of the transfer, is in writing and signed by the owner of the rights conveyed" (17 U.S.C. §204). UK and EU practice points the same way — commissioned work stays with the creator until a signed assignment moves it.

Practical consequences for the clause:

• Use present-tense assignment language ("Developer hereby assigns"), with a present assignment of future works where your jurisdiction allows it, plus an obligation to sign confirmatory documents on delivery.
• Cover the chain. If the agency uses freelancers or a subcontractor, it can only assign what it actually holds. Ask for a warranty that every contributor has signed an equivalent assignment.
• Separate the developer's pre-existing code. Agencies reuse internal libraries and boilerplate, and that is normal. You need a perpetual, irrevocable, transferable licence to those components, not ownership of them.
• List the handover package: repository access, build instructions, environment variables and secrets, signing keys, architecture documentation, design source files, and an inventory of open-source components with their licences.
• Put the repository in your organisation from day one. Owning the GitHub, GitLab or Bitbucket organisation and inviting the agency as a member removes an entire category of exit problem. We cover the handover in detail in app source code ownership, and the contract mechanics in IP ownership in software contracts.

Source code escrow is worth considering when the app runs a business process you cannot pause: a third party holds the code and releases it to you on defined trigger events, typically insolvency or sustained failure to support.

6. Store accounts: who owns the publishing rights

Here is the clause that general software templates never contain, and the one an app development contract needs most: it causes the awkward conversations after a relationship ends.

Which developer account publishes your app? The answer should almost always be an account owned by your company, with the agency added as a user in App Store Connect and Play Console. The cost of doing it properly is trivial: the Apple Developer Program costs 99 USD per year and the Apple Developer Enterprise Program 299 USD per year (Apple), while Google Play charges a 25 USD one-time registration fee (Play Console Help).

Account type also belongs in the contract, because it changes your timeline. Google Play requires personal developer accounts created after 13 November 2023 to run a closed test with a minimum of 12 testers opted in continuously for at least 14 days before they can apply for production access (Play Console Help). An organisation account has no such requirement. A launch plan built on a personal account loses two weeks it never budgeted.

If the app already lives in the wrong account, transfer is possible but conditional. Apple's app transfer criteria require, among other things, that the app has at least one version released to the App Store, that it is not available for pre-order anywhere, and that it is not sitting in Processing for Distribution, Waiting for Review, In Review, Accepted, Pending Developer Release or Pending Apple Release status. In-app purchase product IDs must not collide with product IDs in the recipient's account, and Apple Arcade apps cannot be transferred at all (app transfer criteria). The good news: Apple documents that "during and after the transfer, the app retains its reviews and ratings, and users continue to receive updates."

Settle these in the same clause:

• Who writes store listing copy, produces screenshots and the preview video.
• Who completes age ratings, privacy labels and data-use declarations. Apple has required responses to its updated age-rating questions since 31 January 2026.
• Who holds trader status for the EU. Apple removes apps without a verified trader declaration from the App Store in the European Union under the Digital Services Act, and that declaration belongs to your company, not your agency.
• Who controls signing certificates and Play App Signing keys, and when copies reach you.

Walk the whole sequence with the app launch checklist before you sign, and read how to publish an app for the steps the clause has to cover.

7. Store rejections and annual platform requirements

Apple's rejection numbers explain why this clause earns its place in an app development contract. Answer three questions in the draft.

Who fixes a rejection? Split by cause. Rejections rooted in build quality or guideline compliance — incomplete submissions, crashes, missing demo accounts, undocumented features — sit with the developer. Apple's guideline 2.1 is explicit that submissions "should be final versions with all necessary metadata and fully functional URLs included" and that reviewers need demo account details when the app has a login. Rejections rooted in your business model, content rights or chosen payment flow sit with you. Our breakdown of app store rejection reasons maps the common causes to the party that can actually resolve them.

How many rounds, over what period? "Until the initial release is approved" is the cleanest formulation. Add an outer boundary — 60 days from first submission — so an unresolvable business-model problem does not create an open-ended obligation.

Who owns the platform's annual homework? Raising the target API level, rebuilding against a new SDK, replacing a deprecated permission and answering new policy questionnaires recur every year. Decide at signature whether the first cycle falls inside the warranty period or inside a maintenance agreement. Decided later, it always arrives as a change order.

8. Warranty, maintenance and support

Warranty and maintenance solve different problems, so an app development contract needs separate clauses for them. Warranty fixes the delivered scope when it does not behave as specified. Maintenance keeps the product working as the world moves underneath it.

In the warranty clause, set the period (three to six months after acceptance is common for apps), the covered subject (defects in accepted features), the exclusions (new features, changes forced by a third-party service, modifications made by your own team), and the response commitment for critical defects.

In the maintenance clause, settle five numbers: the recurring fee and what it includes, the support channel and its business hours, response and resolution targets per defect class, who pays for servers and third-party services, and how many releases per year the fee covers. App maintenance cost breaks down the line items behind that fee, and software maintenance agreements gives you a structure for the document itself.

One warning about structure: a maintenance agreement that quietly makes IP assignment conditional on an active subscription hands your vendor a renewal lever. Keep ownership in the development contract and keep it unconditional once the final milestone is paid.

9. Data protection: your developer is a processor

If your app touches user data — nearly all do — your app development contract needs a data processing section, and in the UK and EU that section is not optional.

You act as controller, the agency acts as processor, and Article 28 of the UK GDPR requires a written contract containing specific terms. The regulator's own list covers eight: processing only on your documented instructions, a duty of confidence for everyone with access, appropriate security measures, no sub-processor without your prior written authorisation (with equivalent obligations flowed down and the processor liable for the sub-processor's compliance), help with data subject rights requests, assistance with your own obligations including breach notification and impact assessments, deletion or return of the data at the end of the contract, and submission to audits and inspections (ICO guidance). The same guidance notes it is under review following the Data (Use and Access) Act, so check the current version before you copy wording.

Beyond the mandated terms, four sentences save real money:

• Development and test environments use masked or synthetic data, never a copy of production.
• All agency access to your systems ends at project close, with copies deleted and a written confirmation.
• The agency notifies you of a suspected breach within a fixed number of hours, short enough to leave you time for your own regulatory deadline.
• Confidentiality survives the project for a defined period, and covers your roadmap and metrics as well as code.

If you are still at the pitching stage, how to protect your app idea explains what an NDA does and does not achieve before a contract exists.

10. Termination, exit and dispute resolution

Nobody signs an app development contract expecting to use this clause, which is exactly why it goes unread.

Separate three exits. Termination for cause needs named triggers (payment more than 30 days overdue, a milestone missed by more than X days, a confidentiality breach) and a cure period. Termination for convenience should price itself: accepted milestones paid, the current sprint pro-rated, demobilisation costs capped at a stated figure. Expiry needs nothing more than a date.

Then write the exit procedure, which matters more than the termination right itself. Within a defined number of days after any termination, you receive: the current source code and build configuration, documentation, administrator rights to every account, database exports, signing keys, and a short handover session with the engineers who did the work. Without that paragraph, "we own the code" is a sentence you will be arguing while your product sits frozen.

For disputes, set out the ladder: a named escalation contact on each side, a short good-faith negotiation window, then mediation or arbitration, then courts. Name the governing law and the forum — a cross-border project without a forum clause turns a 20,000 USD argument into a jurisdictional one. Two practical additions: require that work continues during a dispute over anything other than payment, and cap total liability at a figure that is real on both sides (contract value is the usual anchor), while leaving confidentiality breaches, IP infringement and gross negligence outside the cap.

Red flags in a draft contract

None of these phrases proves bad faith on its own. Each one needs resolving before signature.

Read this table next to the vendor questions in how to choose a software development company; the two together make the pre-contract meeting far more productive.

Frequently Asked Questions

Does an app development contract need to be notarised or witnessed?

No. A signed written agreement is enough in the US, UK and EU, and electronic signature platforms satisfy the writing requirement in ordinary commercial contexts. What does need care is the copyright assignment: US law requires a writing signed by the rights owner, so keep the signed assignment, or the clause containing it, with your corporate records rather than in an email thread.

Who owns the code if we never signed a contract?

In most common-law jurisdictions, the developer does. Copyright vests in the author, commissioned software falls outside the US work-made-for-hire categories, and without a signed assignment paying an invoice does not move ownership. You usually hold an implied licence to use the delivered app for its intended purpose, but not to modify it, resell it or hand it to another agency. Fixing this retrospectively means asking for a signed confirmatory assignment, which is a negotiation you no longer control.

How much should the upfront payment be?

A kick-off payment of 20-30% matches the real cost of mobilising a team, reserving engineers and starting discovery. Above 40% you are financing the vendor rather than the project, which is worth asking about directly. Below 10% is also a signal: a team with no commitment from you has no reason to protect your dates over another client's.

What is a reasonable cap on liquidated damages?

A daily rate around 0.1% of contract value with a total cap of 5-10% is the range most vendors will sign and most courts will respect. The cap is the important half. An uncapped daily penalty either gets struck down as a penalty or gets priced into the quote, and you pay for it either way.

Can we move the app to our own developer account later?

Usually yes. Apple supports app transfers when the app has at least one released version, is not in a review or pending-release status, and is not open for pre-order; reviews and ratings survive the move, and the App ID transfers with the app. The transferring account keeps access to historical sales data but loses access to post-transfer sales and analytics. Doing it at the start is still cheaper than doing it during a dispute.

Should maintenance sit inside the app development contract?

Keep them separate. Warranty obligations belong to the development contract and expire; maintenance is a recurring service with its own pricing, service levels and renewal cycle. Separate documents also mean that not renewing maintenance cannot be read as affecting the assignment or warranty terms you already paid for.

Who is responsible when a store policy changes mid-project?

Decide in the contract rather than after the fact. The workable split: the developer absorbs changes announced before the scope annex was signed, and policy changes announced afterwards become a change order with days and cost shown separately. Platform requirement deadlines are published months in advance, so a clause requiring the developer to flag them in the project schedule costs nothing and prevents the argument.

Is a fixed price better than time and materials?

Neither wins on principle. Fixed price suits a well-specified first release and transfers estimate risk to the vendor, which it prices in. Time and materials suits discovery-heavy work and keeps you flexible, provided you insist on a cap, a written reporting rhythm and the right to stop at any sprint boundary. The app development contract clause that matters in both models is the same one: change control.

An app development contract does not make a project good. It decides which party has the stronger position when something goes wrong — and in app projects something usually does, because two platform owners get a vote on your release. Bringing these ten clauses to the table early also changes how a serious vendor reads you: the questions show you know which line items create real cost.

If you want the scope annex, milestone plan and handover package drafted properly for your project, take a look at our mobile app development service or get in touch and we will put the clause list together with you.