Almost certainly yes. If your app stores anything that identifies a person — an email address, a name, a user account — you should have a privacy policy, and you should have it before you launch. Most people asking “do I need a privacy policy for my app” are hoping the answer is “not yet, I’m too small.” Mostly it isn’t. European and UK data protection law sets no revenue or headcount floor on the duty to tell people what you collect. California has required a posted policy from commercial sites and apps collecting personal information since 2004, with no revenue or user threshold. Apple and Google reject submissions that don’t link to one. The trigger is your first stored email address, not your first thousand users.
This is information, not legal advice. I’m not a lawyer and this is no substitute for one. It’s a plain description of what the rules ask for, so you know what you’re looking at when you write or generate a policy. If your app touches health records, children’s data or money that isn’t yours, pay a lawyer.
“Personal data” is a wider word than it sounds
Personal data means anything that can be traced back to a particular person. An email address or a name. Also the things you forgot you had: IP addresses in your server logs, user IDs, device identifiers, uploaded photos, whatever your analytics records about one visitor. To find out what you hold, read your database column names — every one that could be tied back to a human being counts — then your environment variables, for every outside service that receives any of it.
Three separate rules, and each is enough on its own
The EU and UK. The GDPR reaches companies outside Europe when they offer goods or services to people in the EU, or track their behaviour there. The test is whether you’re aiming at European users, not merely reachable from Europe — and regulators are explicit about that line. Recital 23 and the European Data Protection Board’s guidance both say a site simply being reachable in the EU is not enough, and that services provided to someone in Europe inadvertently or incidentally fall outside the regulation. What brings you in is evidence you envisaged those users: prices in euros, a translated interface, EU-targeted marketing, naming European customers. Those are easy to acquire without noticing, so if any of them describe you, work on the assumption you’re in scope. The law never says the words “privacy policy.” Article 13 says you must tell people certain things at the moment you collect their data, and a policy is how everybody does that. The one size-based carve-out in the regulation concerns internal record-keeping at 250 employees — and it is narrower than it looks, since it falls away where processing is routine rather than occasional, which describes most apps. It does not excuse the notice either way. The UK inherited these rules at Brexit, but has since started to diverge: the Data (Use and Access) Act 2025 changed cookie consent, automated decision-making and parts of the record-keeping duty. The duty to tell people what you collect is not one of the things that changed.
California. The CCPA has thresholds most small apps never reach — $26,625,000 in annual revenue for 2025–26, a figure adjusted for inflation every couple of years, or 100,000 California consumers or households, or half your revenue from selling or sharing personal information. That last word is worth reading twice: post-CPRA, “sharing” covers cross-context behavioural advertising, so it is easier to trip than a plain sale of data. But an older law, CalOPPA, has applied since 2004 with no threshold at all: any commercial site or service collecting personally identifiable information from Californians must conspicuously post a policy. That one catches far more small apps — though it defines the triggering information as a specific list (name, address, email, phone and similar) rather than anything traceable to a person, and an operator is formally in violation only after failing to post within 30 days of being notified it hasn’t.
The app stores. Apple’s review guideline 5.1.1 wants a link to your policy in two places: the App Store Connect metadata field, and inside the app somewhere easy to find. Google Play requires one from every app, including apps that collect nothing, plus a completed Data safety form. This one bites first: it stops the release outright.
What it actually has to say
A policy that satisfies Article 13 answers at least eight questions. Who you are, at an address a person can email. What you collect. Why, and on what legal basis — consent, a contract with the user, or an interest of yours you can explain. Who else sees it: payment processor, database host, email sender, analytics, AI provider. Whether it leaves the country. How long you keep it. How someone gets a copy, a correction or a deletion, and how they complain to a regulator if you ignore them. How to withdraw consent, where consent is what you relied on. Article 13 asks for a few more where they apply — a data protection officer’s details if you have one, whether handing over the data is actually required and what happens if someone declines, and whether you make automated decisions about people — so treat eight as the shape of the thing, not a finish line.
The third-party list is where generated policies go wrong, because a generator can’t see your code and guesses. If Stripe, Supabase and Resend hold your users’ data, the policy has to name them. Apple also wants it to explain how deletion works and how someone revokes consent, and to confirm that the services you share data with give that data the same protection your policy promises.
What happens if you skip it
The app store consequence is immediate and certain: rejection, and a resubmission cycle you didn’t plan for. The legal consequence is slower, and worth describing honestly because the internet does not.
You will read about fines of €20 million or 4% of global turnover. Those are statutory ceilings written for the worst conduct by the largest companies, not a price list. Regulators have a ladder of options below them — Article 58 gives them warnings, reprimands, and orders to fix something by a set date — and published enforcement against small operators tends to start near the bottom of it. Nobody can promise you which rung you land on, and a missing policy is not the only thing a complaint will surface. But an order telling you to publish one is a likelier first move against a small app than a headline fine. Not a reason to skip it. A reason not to panic, and to spend the afternoon.
Getting one, this week
Write the inventory first: every field you store, every service that receives it, how long you keep it. Then use a generator or template, and edit the parts it guessed at, because those are the parts that matter. Host it at a plain URL that works without logging in, link it from your footer, sign-up form and settings screen, and date it.
And be clear what it isn’t: a policy describes what you do with data, and does nothing to protect it. An accurate policy about a database anyone can read just documents the problem. Protection is the separate job, and the one worth doing first — the pre-launch checklist covers it, and if you built on Lovable or something like it, the three settings most likely to be wrong is a shorter read.
npx launchprep reads your codebase for the protection side of this, and flags the case this article opens with: personal data in your schema and no policy anywhere in the project. It runs on your machine and the free checks are unlimited. What it cannot do is tell you whether the policy you wrote is accurate — nothing automated can.
Questions people ask
My app doesn’t collect any data. Do I still need one? For the app stores, yes — Google requires the form and the link even from apps that collect nothing. Check the claim first. Crash reporting, analytics, a contact form and server logs holding visitor IP addresses all count, and most people have one without ever deciding to.
Can I copy a policy from an app like mine? Bad trade. Theirs names their services, retention periods and contact details, so yours would describe someone else’s app — and a policy that doesn’t match what you do is worse than a plain one, because now the inaccuracy is in writing. It’s also their copyrighted text.
Do I need a cookie banner too? Different rule, different trigger. Banners come from the ePrivacy rules, about storing or reading things on someone’s device. A login cookie your app cannot work without generally needs no consent; advertising pixels do. Analytics is where the EU and UK have split — in the EU it generally still needs consent, while the UK exempted low-risk first-party analytics from February 2026, but only where the data isn’t also feeding ad targeting, which rules out a lot of default analytics setups. You can easily need a policy and no banner.