How to write a privacy policy for a small UK app

This is not legal advice. UK GDPR, the Data Protection Act 2018, PECR, and Apple’s privacy requirements can change. Confirm the current expectations with the Information Commissioner’s Office and with Apple’s App privacy details, and take advice if your situation is not simple. The privacy manifests guide covers what you declare in the app and in App Store Connect; this article is about the public policy those declarations should agree with.

A policy is a truthful description, not a shield

The ICO expects a privacy notice to tell people, in language they can understand, who you are, what you collect, why, on what legal basis, how long you keep it, who you share it with, and what rights they have. A notice that disagrees with the product is worse than a short one. If the policy says “we never share data with third parties” and a crash SDK is sending data to a vendor, the policy is wrong, and the App Store privacy labels should already have given the same fact away.

Two tests help:

• Could a careful person, or an assistant summarising the page, lift a sentence and not be misled?
• Would you sign your name under every third-party SDK you listed? If you are not sure what an SDK collects, find out or remove it.

I keep the public policy for this site at /privacy, and I rewrite it when the product changes, not on a calendar. An app policy should have the same habit: it is part of maintaining the app after launch, not a launch-week chore you never open again.

What a small app usually has to say

For a typical indie iOS app, sold in the UK, a complete notice usually covers:

• Who the controller is — your name or company name, and a contact email. If you are a sole trader in England, say so in ordinary words. If a company is the controller, use the registered name.
• What the app is, in one or two sentences, so the rest of the notice has a context.
• The information you collect, grouped by how it arrives: information the person types, information the device provides with permission (camera, location, contacts, photos), and information that is generated (crash logs, basic diagnostics).
• What you use it for, and the lawful basis under UK GDPR for each purpose (contract, legitimate interests, consent, a legal obligation, and the other bases the ICO lists). Don’t pick a basis because it “sounds softer.”
• Who you share it with, named where you can: Apple, a hosting provider, an email delivery service, a payment platform, an analytics or crash tool. “Trusted third parties” is not a list.
• Where it is stored and for how long, including whether a provider is outside the UK and what you have done about that, in the terms the current guidance expects.
• The person’s rights, and how to use them, plus the right to complain to the ICO.
• Children, if there is any chance the app will be used by them, and the age rating you already claimed.
• Changes — that you will update the policy when the practice changes, and where the current version lives.

If you also have a website, a support inbox and an account system, don’t write three contradictory notices. Either keep one policy with clear sections, or keep two that cross-link and agree.

Apple will also want a privacy policy URL for many apps, and the App Store privacy labels have to match. The public policy is the prose; the labels and the privacy manifest are the structured version. All three should be telling the same story.

Data you collect, data you never collect

Be specific, and be willing to say what you do not do. A short “we don’t sell your data, we don’t run adverts, we don’t use the information for profiling” paragraph, when it is true, is one of the most useful things you can write.

Group collection in a way a person can scan:

• You give it to me: name, email, a message, an account handle, a photo they chose.
• The app asks the system for it: camera, microphone, location, contacts, photo library, Bluetooth, health data, and so on. Each of those should already have a purpose string in the app, and should be mentioned here in the same words.
• The app or a library generates it: crash traces, a purchase receipt, a technical log, a device type.

If a category is empty, say so. “This app does not use your location” is a better sentence than a heading called Location with nothing under it, or, worse, a copied clause about “geo-location data we may collect.”

Don’t describe a data type you might add “one day.” Add it to the policy when you add it to the app, in the same release if you can.

For a tiny app with no account, the honest collection section can be very short: “I do not have user accounts. The only personal data I hold is what you send to the support email, and I use it to reply.” If that is no longer true the day you add a mailing list, the policy has to change that day too.

Analytics, crashes and third-party SDKs

This is where copied templates usually lie. Every SDK is a processor or a controller in its own right, or sometimes a bit of both, and you have to know which. Read the vendor’s documentation, the data it actually sends, and the terms you agreed to. Then write a paragraph for each one, or a table if you have several:

• the name of the vendor
• what it is for (crashes, performance, analytics, payments, sign-in)
• the kind of information it receives
• whether it uses that information for its own purposes, including advertising or its own analytics
• a link to that vendor’s policy

If you use Apple’s own frameworks only, say so. If you use a third-party crash reporter, say whether identifiers are sent, whether you can turn it off, and whether it is on by default. If you use analytics, be honest about cookies or similar technologies on any associated website, and about identifiers in the app. The companion piece on cookie-free analytics and UK GDPR covers the website side, and is also not legal advice.

A privacy manifest and “required reason” APIs will already have forced you to list some of this for App Review. Use that work. Don’t invent a second, softer list for the public page.

Security measures can be mentioned in ordinary language — transport encryption, access limited to you, a host in a named country — without writing a marketing paragraph about “bank-grade” anything. If you have set baseline security headers on the site that hosts the policy, that is housekeeping; it is not a substitute for the notice itself.

Purchases, accounts and support email

Money and identity need extra care, because they usually involve other companies.

• App Store purchases are made with Apple. Say that you receive the fact of a purchase (and whatever identifiers Apple gives you to unlock it), and that payment details are handled by Apple, not by you, if that is true. Don’t claim you “never see any purchase data” if you hold a receipt or an original transaction id.
• Accounts need a paragraph about sign-in (including Sign in with Apple, if you use it), about what is stored, about deletion, and about what happens to the person’s content when the account goes. Apple’s review rules on account deletion should already have made you build this; the policy should describe the path as it really is, including how long deletion takes.
• Support email and contact forms are still personal data. Say what you keep, where, and for how long. “Until the conversation is finished, and then for up to X months in case we need the context” is the kind of sentence people can test you against. On this site, enquiries have a published retention period; an app can have the same kind of definite answer.

If you market to existing customers, or you might, say so, and don’t bury an opt-out in a clause about “legitimate interests we may have from time to time.” If you do not market, a single sentence that you don’t is worth having.

UK GDPR rights, in plain English

The ICO publishes the list of rights. In a small-app policy, you should describe them in words, not only by their article numbers:

• access to the personal data you hold
• correction of inaccuracies
• erasure, in the circumstances the law allows
• restriction of, and objection to, some kinds of processing
• data portability, where it applies
• a complaint to you, and to the ICO

Tell people how to ask: an email address is enough for a small app, if you actually read it. Say that you will respond within the current statutory period (the ICO currently talks about one month as the usual period, but confirm that when you write). Don’t invent a web portal you have not built, and don’t ask for a posted letter if you would not want one yourself.

If you don’t make automated decisions that have legal or similar effects, say so. If you do, you have more to explain, and you should take advice.

Children need a clear line. If the app is not for children, say the age you have in mind and that you don’t knowingly collect their data. If it might be, the ICO’s and Apple’s current rules for children’s data are stricter than a standard notice; don’t ship that category from a template.

Where to host it and how to link it

Host the policy on a stable HTTPS URL that you control, such as https://example.com/privacy, not only as a PDF inside the app, and not only as a screen that disappears when the app is deleted. The App Store needs a URL a reviewer can open without installing a special build. The in-app settings should link to the same URL, or to the same text kept in sync.

A few hosting details are worth getting right:

• The page should be readable without an account, and should not sit behind a cookie wall.
• It should have a date (or a version) so a person can see whether it has changed.
• It should be indexable if the rest of the marketing site is, unless you have a reason to hide it. A policy is not a secret. The robots.txt & llms.txt Generator can help you make sure you have not disallowed /privacy by accident.
• The language should match the app. A UK app can be written in British English; if you localise the app, localise the policy or be honest that the English notice is the official one.

Don’t put the only copy in a Google Doc with “anyone with the link,” and don’t use a URL shortener as the official address.

A section-by-section template, and when to get advice

The following is a skeleton, not a finished policy, and not a form you should publish unchanged. Replace every bracket, delete any section that is not true, and add anything that is true but missing. Then have someone who did not write the app read it once, out loud.

1. Who I am — [name / company], [role as controller], [email]. Where I am based.
2. The short version — five or six sentences that would still be true if someone read nothing else.
3. Information I collect — grouped as above, including an explicit “I do not collect…” list where it helps.
4. What I use it for, and the basis I rely on — one short subsection per purpose.
5. Services and other companies — named processors and links to their notices.
6. How long I keep it — definite periods where you can, and the rule you use where you cannot.
7. Your rights — the list, the email, the ICO.
8. Children.
9. If you email me or use a contact form.
10. Purchases and accounts, if any.
11. Changes to this notice, and the date of this version.

Use the Word Counter if you like, not to hit a mystic length, but to keep the short version actually short. A small app policy that runs to many thousands of words is usually a copied one.

Get advice, rather than relying on this skeleton, if you: process children’s data; process health, finance or other special category data; combine data from several apps to profile people; advertise based on what people do in the app; operate in a sector with its own rules; or have a joint-controller arrangement with someone else. A cheap policy generator is not a stand-in for that advice, and neither am I. Budget a little time for the notice, the same way you budget for other non-code work in what an iOS app really costs; it is cheaper than rewriting it under review, or after a complaint.

Key takeaways

• Write a truthful notice in plain English that matches the app, the privacy labels and the privacy manifest. It is not a shield.
• This is not legal advice; confirm current ICO and Apple guidance, and take advice if your case is not ordinary.
• Name what you collect, what you don’t, every SDK and processor, the purposes and lawful bases, and how long you keep the information.
• Describe UK GDPR rights with a real contact method, and host the policy on a stable, public HTTPS URL that the app and the App Store both use.
• Update the policy in the same release as a product change, not months later.

If you want a second pair of eyes on how clearly a policy is written, tell me about it. For legal sign-off, ask a solicitor or a specialist who can advise you.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.