The four documents every SA app needs
Most app legal problems trace back to a missing document or two documents that contradict each other. The pack below is drafted as one cross-referenced set — the terms point to the privacy policy, the subscription terms mirror the store's billing mechanics, and the child-data position is consistent across all four. For the licence document itself — enforceability, click-wrap mechanics, CPA limits on disclaimers — see the dedicated EULA guide rather than a summary here.
App T&Cs / EULA
The licence and rules of use between you and the person who installs the app — acceptance mechanics, restrictions, account rules, liability within CPA limits. An app with a connected backend usually needs both a licence and service terms. Full treatment on our EULA page; this pack drafts them to work together.
POPIA privacy policy
A standalone, plain-language notice describing what the app actually collects — account data, device identifiers, analytics, crash reports, SDK data flows — why, who receives it, and how users exercise their rights. It must match reality: store review teams compare your declarations against observed app behaviour.
Purchase + subscription terms
In-app purchase and subscription terms aligned to store billing rules: what renews, when, at what price, how trials convert, and how the user cancels. Where the consumer is a natural person, CPA fixed-term rules shape renewal and cancellation mechanics — your terms cannot promise less than the Act gives.
Age + child-data handling
A documented position on under-18 users. POPIA treats a child's personal information as specially protected: processing is prohibited unless an exception applies, the default route being prior consent of a competent person. Your age-gating, consent flow and data minimisation for minors belong in writing before launch.
Children and apps: the s34 problem
POPIA sets the bar higher than most founders expect: a child is anyone under 18 — not 13, the threshold US-drafted templates assume. Section 34 prohibits processing a child's personal information outright unless a section 35 exception applies, and for a commercial app the workable exception is prior consent of a competent person — a parent or guardian. That makes child data a specially protected category in the same league as health or biometric information, not a footnote in the privacy policy.
Practically, this means three things. First, an age gate that genuinely asks — a self-declared birthdate is the accepted starting point, but you must act on the answer rather than collecting it and ignoring it. Second, a competent-person consent flow you can evidence: an email or in-app confirmation loop to the parent, recorded, before a child account starts generating data. Third, data minimisation for minors — no behavioural advertising profiles, no unnecessary identifiers, nothing collected that the child-facing feature does not need. Mixed-audience apps — not aimed at children but obviously attractive to them — are the hard case: the defensible position is to design the default experience as if minors are present until age is established, and to document why your approach is reasonable. An app that simply hopes its users are adults has no position at all.
Store rules vs SA law
Apple and Google enforce their own developer policies — privacy-nutrition labels, data-safety declarations, account-deletion requirements, billing rules — and passing store review feels like compliance. It is not. The store minimums are contractual conditions of distribution, drafted under foreign law for the store's protection; they do not deliver CPA fairness, POPIA lawful-processing conditions, or section 69 marketing rules. Conversely, full POPIA compliance does not satisfy the stores either: the structured disclosures are their own format with their own review process.
The discipline that keeps you safe in both systems is three-way consistency: the data-safety declaration must match the privacy policy, and both must match what the shipped app — including every embedded SDK — actually does. A mismatch is enforcement bait twice over: the Information Regulator sees a transparency failure under POPIA, and the store sees a misdeclaration that can suspend the listing. The drafting workflow should therefore start from an audit of real data flows, not from a template, with the store declarations and the privacy policy generated from the same source of truth.
Subscriptions, trials and cancellations
Where your subscriber is a natural person, CPA section 14 governs the fixed-term mechanics that app subscriptions live on: the consumer may cancel on notice, renewal cannot be silently locked in, and cancellation penalties must be reasonable. Section 14 does not apply to juristic persons, so a B2B tier has more freedom — but a consumer app must build its renewal and cancellation flows around the Act, not around what the billing platform permits. The store's own billing rules (auto-renew disclosures, in-store cancellation, trial-conversion notices) run in parallel; your terms must mirror those mechanics honestly rather than describing a flow that does not exist.
The growing risk area is dark patterns. A trial that converts without a clear, timely warning; a cancellation path buried three menus deep while signup takes one tap; countdown timers and guilt-tripping copy on the cancel screen — these invite scrutiny under section 40 (unconscionable conduct) and section 41 (false, misleading or deceptive representations). The safe design rule is symmetry: cancelling should be as easy as subscribing, and every price, renewal date and trial-end consequence should be stated where the consumer makes the decision, not in a document they will never open.
Push, tracking and marketing
POPIA section 69 draws the line for electronic marketing: unsolicited direct marketing by electronic communication requires the data subject's consent — opt-in, not opt-out — subject to a narrow existing-customer exception for similar products with an opt-out offered at collection and in every message. Map your notifications against that line. A push notification about the user's own transaction, security or service status is not direct marketing; a push promoting an upgrade, a sale or a partner offer is. Mixed-purpose notifications get judged by their marketing payload, so keep transactional channels clean and run promotions through a separately consented channel the user can switch off without losing service messages.
Tracking is the quieter exposure. Analytics, attribution and advertising SDKs collect device identifiers and behavioural events the moment the app opens — that is processing of personal information with you as the responsible party, whether or not you ever look at the data. POPIA requires it to be disclosed in the privacy notice, supported by a lawful basis, covered by operator terms with the SDK vendor, and treated as a section 72 cross-border transfer where the endpoint is offshore — which it almost always is. Our POPIA for tech companies guide covers the underlying framework; the app-specific work is the SDK audit that makes the disclosures true.
Frequently asked
Do I need both a EULA and terms and conditions for my app?
Usually yes, or one carefully unified document doing both jobs. The EULA is a copyright licence covering the installed software — use rights, restrictions, ownership. Terms of service govern the ongoing service relationship behind the app: accounts, payments, acceptable use, suspension. A purely offline utility app can survive on a EULA alone; the moment there is a login, a backend, or a subscription, you need service terms too. Drafting them together prevents the gaps and contradictions that come from bolting a template EULA onto template T&Cs.
What does my privacy policy need to satisfy the app stores?
Both stores require a publicly accessible privacy policy linked from your store listing and inside the app, and both require structured privacy disclosures — Apple's privacy "nutrition" labels and Google Play's data-safety section — describing what data the app collects and shares. The critical compliance point is consistency: the declarations, the policy and the app's actual behaviour (including every SDK you embed) must say the same thing. For SA users the policy must also do its POPIA job: identify the responsible party, the purposes, recipients, cross-border transfers and the data subject's rights, in plain language.
How do I handle under-18 users?
POPIA defines a child as a natural person under 18 who is not legally competent to take decisions on their own behalf, and section 34 prohibits processing a child's personal information unless a section 35 exception applies — the practical route for an app being prior consent of a competent person, typically a parent or guardian. If your app is aimed at or attractive to minors, you need an age gate, a competent-person consent flow you can evidence, and aggressive data minimisation for child accounts. If your app is adult-only, say so in the terms, ask for age at signup, and act on what you learn.
Can users demand that I delete their data?
Yes. POPIA gives data subjects the right to request correction or deletion of personal information that is inaccurate, excessive, out of date or no longer lawfully held, and the retention rules require you to stop keeping data once the purpose is exhausted. Both stores have also pushed in the same direction — Google Play requires apps that allow account creation to offer account deletion, in-app and via a web link. Build the deletion path before launch: a deletion request you cannot execute is a finding waiting to happen.
Do South African rules apply if my app sells overseas — and does GDPR reach me?
Both directions matter. POPIA applies where you are domiciled in South Africa, regardless of where your users sit, and section 72 governs sending personal information out of SA — relevant the moment your analytics or hosting is offshore. In the other direction, GDPR can reach an SA app that offers goods or services to people in the EU or monitors their behaviour, even with no EU office. If you have meaningful EU users you are likely dual-regulated; see our POPIA-GDPR dual-compliance guide for how the two regimes are reconciled in one document set.
Who handles in-app purchase disputes and refunds — me or the store?
Practically, the store processes the payment and operates the first-line refund machinery, under its own policies. Legally, the CPA sits between you and an SA consumer regardless: section 14 governs fixed-term renewals and cancellation for natural persons, and sections 40 and 41 prohibit unconscionable conduct and false or misleading representations — which is where manipulative cancellation flows and buried renewal terms create risk. Your subscription terms should mirror the store's billing mechanics honestly and give the SA consumer at least what the Act requires, because "the store handled it" is not a defence to a CPA complaint against you.
What about the SDKs in my app — analytics, ads, crash reporting?
Every SDK that receives device identifiers, usage events or any user data is processing personal information, and you are answerable for it. POPIA requires you to disclose the categories of recipients in your privacy notice, bind operators processing on your behalf to written terms, and treat offshore SDK endpoints as cross-border transfers under section 72. The store layer doubles the exposure: your data-safety and privacy-label declarations must cover SDK collection too, and store review teams increasingly detect undeclared SDK traffic. Audit your SDK list before drafting — the policy must describe the app you actually shipped.
What does an app legal pack cost in South Africa?
From R14,000 for the four-document consumer-app pack: app T&Cs/EULA, POPIA privacy policy mapped to your actual data flows, in-app purchase and subscription terms, and the age/child-data framework — drafted as one cross-referenced set and aligned to your store listings. Apps with unusual risk profiles (children's apps, health or financial data, EU user bases needing GDPR dual-compliance) price higher once the additional layers are scoped.