What is a mobile app development agreement?
Is a mobile app development agreement enforceable in South Africa — and who owns the app?
“No assignment of copyright and no exclusive licence to do an act which is subject to copyright shall have effect unless it is in writing signed by or on behalf of the assignor, the licenser or, in the case of an exclusive sublicence, the exclusive sublicenser, as the case may be.”
“a computer program, the person who exercised control over the making of the computer program”
“Where a person commissions the taking of a photograph, the painting or drawing of a portrait, the making of a gravure, the making of a cinematograph film or the making of a sound recording and pays or agrees to pay for it in money or money’s worth, and the work is made in pursuance of that commission, such person shall, subject to the provisions of paragraph (b), be the owner of any copyright subsisting therein by virtue of section 3 or 4.”
“Coetzee was all along in constant contact with Haupt and he accepted and executed detailed instructions from Haupt. As he progressed he submitted his work to Haupt for it to be checked and approved by him. … one does not need to be a computer programmer to be able to control the writing of a computer program.”
“A responsible party may, subject to section 35, not process personal information concerning a child.”
“A responsible party must, in terms of a written contract between the responsible party and the operator, ensure that the operator which processes personal information for the responsible party establishes and maintains the security measures referred to in section 19.”
“A responsible party in the Republic may not transfer personal information about a data subject to a third party who is in a foreign country unless—”
When you need a Mobile App Development Agreement
- You are commissioning an agency, studio or freelancer to build a new iOS or Android app — a booking, ordering, loyalty, delivery or field-service app — and so far you have only a quote and a payment schedule.
- You are moving an existing app away from a previous developer and need the code, the store listings and the signing keys handed over cleanly.
- The app will collect personal information — location, contact details, payment or health information, or data about children — and the developer will host the backend or support the app with access to live data.
- The studio builds on its own platform or white-label framework and will license, rather than transfer, part of what you are paying for.
- You are raising investment or selling the business, and the investor’s or buyer’s due diligence asks you to prove that the company owns the app it trades on.
What a Mobile App Development Agreement should contain
Scope, platforms and supported devices
Say exactly what is being built: iOS, Android or both; separate native apps or one cross-platform codebase (such as Flutter or React Native); the screens and features; whether the backend, admin dashboard and integrations with payments, maps or your existing systems are included; and the minimum operating-system versions and devices the app must support. In South Africa that list should include popular budget and mid-range Android phones, not only the latest iPhone. Anything not written into the scope will later be argued to be a paid change.
Ownership of the code, designs and backend (s 22(3) assignment)
A signed, written assignment of copyright in everything made for you — the app code for each platform, the backend code, the database design, screen designs, icons and documentation — so that the section 22(3) formality is met. The usual balance is that ownership passes milestone by milestone as each payment is made. Where the studio reuses its own pre-existing frameworks or components, you need a permanent, royalty-free licence to keep using, changing and transferring them as part of your app, together with the studio’s consent to you modifying and rebranding the app later.
Source code, signing keys and store accounts in your name
The code should live in a repository (such as GitHub, GitLab or Bitbucket) owned by your business, with the developer committing to it regularly — not on the studio’s machines until the final invoice is paid. The agreement should require handover of build instructions, environment settings, API keys, push-notification credentials and the certificates and keys used to sign the app, and should state that the Apple Developer and Google Play developer accounts are registered to your business, with the developer given team access only. Whoever holds the accounts and keys controls the listing, the ratings and every future update.
Third-party SDKs and open-source licences
A register of every SDK and open-source library in the app, its licence and the data it collects, with no new SDK — especially analytics, attribution or advertising SDKs — added without your written approval. Because an app is distributed to users’ phones, copyleft licences such as the GPL can bite in ways they may not for a hosted service, so the developer should warrant that nothing in the app obliges you to publish your own code. The same register feeds your privacy policy and the store privacy declarations, which must match what the app actually does.
Backend, hosting and POPIA operator terms
Put the cloud hosting account (for example AWS, Google Cloud or Azure) and other service accounts in your business’s name, and record where user data will be stored. If the developer hosts, supports or tests with real user data it is your operator, so POPIA section 21 requires written terms obliging it to keep the data secure and to tell you immediately of a suspected breach; servers outside South Africa must satisfy section 72. The app should ask only for the phone permissions it genuinely needs — location, camera, contacts — and if children may use it, the age gate and parental-consent flow belong in the scope from day one.
Acceptance testing, store approval and milestone payments
A written test plan with objective acceptance criteria, a list of test devices and OS versions, beta builds through TestFlight or a Google Play testing track, a fixed period for you to test, and a fix-and-retest cycle for defects. Payments should follow accepted milestones — design sign-off, beta, store submission, launch — rather than calendar dates. Neither party controls Apple’s or Google’s review, so say who fixes what if a build is rejected: rejections caused by the developer’s code or by ignoring published store guidelines at its cost; rejections caused by your content or business model as a change request. A late-delivery penalty must be expressly stipulated for the delay, because under section 2(2) of the Conventional Penalties Act 15 of 1962 accepting a late build otherwise forfeits it.
Bug-fix warranty and post-launch OS-update support
A period after acceptance — typically 6 to 12 months — during which the developer fixes defects against the agreed specification at its own cost, with response times by severity. The warranty does not normally cover keeping the app working when Apple or Google release a new operating system or change their store requirements: that is adaptive maintenance, and it belongs in a separate support and maintenance agreement, agreed before launch so the app is not stranded on an old OS version.
Termination, handover and escrow if the developer walks away
Say what happens if the developer stops work, goes quiet, is liquidated or is terminated for breach: you pay for accepted work and receive the code, designs, credentials and documentation for everything paid for, plus reasonable handover help for a replacement developer. If the studio keeps ownership of its own platform and licenses it to you — common with white-label app builders — add a source-code escrow, under which the code is lodged with an independent agent and released to you on defined triggers such as insolvency or abandonment of the product.
Mobile app vs website vs general software development agreements
| Feature | Mobile app development | Website development | General software development |
|---|---|---|---|
| How it reaches users | Through the Apple App Store and Google Play; every release is reviewed and can be rejected | Published on your own domain and hosting; no store gatekeeper | Installed or hosted for your staff or customers; no store gatekeeper |
| What you must control | Store developer accounts, signing keys, push-notification credentials, code repository and backend hosting | Domain name, hosting, content-management admin access and code or theme files | Code repository, servers, licence keys and documentation |
| Testing focus | A matrix of phones and OS versions, including budget Android devices | Browsers and screen sizes | The agreed specification in your own environment |
| After launch | New iOS and Android versions and changing store rules force regular adaptive work | Content-management, plugin and security updates | Depends on the system; usually a support agreement |
| Privacy hot spots | Phone permissions (location, camera, contacts), SDK data flows and children | Cookies, contact forms and analytics | Whatever personal information the system processes |
Common South African pitfalls
- Letting the studio publish the app under its own Apple or Google developer account. The listing, the ratings, the user base and the power to push updates then sit with the studio, and moving the app to your account later depends on the store’s transfer process and on the studio’s cooperation — leverage you lose the day you fall out.
- Relying on the quote or an email that says “you will own the app”. Section 22(3) of the Copyright Act requires a written assignment signed by or on behalf of the developer. Unless you can prove you controlled the making of the code — a factual fight after Haupt — an arm’s-length studio usually keeps the copyright, and payment alone changes nothing.
- Paying the final invoice before you hold the code and the keys. If the source code sits in the studio’s private repository and the signing keys and push-notification credentials stay on its systems, a replacement developer may have to rebuild the app — or may be unable to publish updates to your existing listing.
- Not controlling the SDKs. A developer who quietly adds an analytics or advertising SDK changes what your app collects and where the data goes, often to servers outside South Africa. Your privacy policy and store privacy declarations are then wrong, and the offshore flow must still meet POPIA section 72.
- Assuming the bug-fix warranty covers the next iOS or Android release. A warranty fixes defects against the agreed specification; keeping the app compatible with new operating systems and store requirements is a separate, paid service. Without a support agreement in place at launch, the app can be stranded the first time the platforms move on.
- Writing in a late-delivery penalty and then accepting a late build without reserving it. Under section 2(2) of the Conventional Penalties Act a party who accepts late performance cannot claim a penalty for the delay unless the penalty was expressly stipulated for that delay — and section 3 lets a court reduce a penalty that is out of proportion to the prejudice actually suffered.
Frequently asked questions
Who owns the code if I pay a developer to build my app in South Africa?
Not necessarily you. For computer programs the Copyright Act makes the author the person who exercised control over the making of the program, so an arm’s-length studio that runs the build its own way usually owns the code even though you paid. A client who directs and approves the work in detail may be the author (Haupt v Brewers Marketing Intelligence, SCA 2006), but that is fact-specific — the safe course is a written assignment signed by the developer under section 22(3).
Should the App Store and Google Play accounts be in my name or the developer’s?
Yours. Register the Apple Developer and Google Play developer accounts to your business and give the developer team access to build and submit releases. The account holder controls the listing, the ratings and every future update, so an app published under the studio’s account effectively stays with the studio until it agrees to move it.
What happens if Apple or Google rejects the app?
Neither you nor the developer controls store review, so the agreement should allocate that risk in advance. A sensible split is that the developer fixes, at its own cost, rejections caused by its code or by failing to follow the published store guidelines, while rejections caused by your content, pricing or business model are handled as paid change requests. Tie the launch milestone and its payment to that process, not to an approval date nobody can promise.
Do I need source-code escrow for a mobile app?
Often not, if the agreement assigns the code to you and it is committed to a repository you own as the work progresses — you then already hold what escrow would give you. Escrow earns its keep when the studio keeps ownership of its own platform or white-label framework and only licenses it to you: the code is lodged with an independent agent and released to you if the studio becomes insolvent or abandons the product.
Is my app developer an operator under POPIA?
Yes, if it hosts the backend, provides support with access to live data, or tests with real users’ information — it is then processing personal information on your behalf. Section 21 of POPIA requires a written contract obliging an operator to maintain security measures and to notify you immediately of suspected unauthorised access. If the servers are outside South Africa, the transfer must also satisfy section 72.
What if children will use the app?
POPIA treats a person under 18 as a child, and section 34 prohibits processing a child’s personal information unless a section 35 exception applies — for most apps, the prior consent of a competent person such as a parent or guardian. Raise it with the developer at the scoping stage: the age gate, the parental-consent flow and the limits on what child accounts collect are features that must be built and tested, not sentences added to the privacy policy afterwards.
Does the bug-fix warranty cover new iOS and Android versions?
Usually not. A development warranty — typically 6 to 12 months from acceptance — covers defects measured against the agreed specification. Adapting the app to new operating-system versions, new devices and changed store requirements is adaptive maintenance, which should be priced in a separate support and maintenance agreement signed before launch.
Is the development agreement the same as my app’s terms and conditions?
No. The development agreement is between you and the developer and governs the build, ownership and handover. The app’s terms and conditions, end-user licence and privacy policy are between you and the people who download the app; they are separate documents, drafted to match what the finished app actually does.
Sources & authority
- Copyright Act 98 of 1978, ss 1(1), 2(1)(i), 11B, 21 and 22
- Haupt t/a Softcopy v Brewers Marketing Intelligence (Pty) Ltd and Others (118/05) [2006] ZASCA 40; 2006 (4) SA 458 (SCA) (29 March 2006)
- Protection of Personal Information Act 4 of 2013, ss 1, 21, 34, 35 and 72
- Conventional Penalties Act 15 of 1962, ss 1–3
This guide is general information, not legal advice. It reflects the law as at October 2026.