A privacy policy is a plain statement of what your app does with people’s information. Both major stores ask for a link to one, regulators expect it to be truthful, and users sometimes read it before deciding to trust you. This guide lists the sections a mobile app policy normally covers, offers wording tips, and explains how to publish it at an address that will last. It is a practical outline, not legal advice, and it does not replace a review by a qualified professional where laws such as data protection rules apply to your users.
Start from facts, not from a template
The most common failure is a policy that describes an imaginary app. Before writing a word, build an inventory of the data your app handles: what you collect, where it goes, who receives it, and why. The same inventory powers the Google Play Data safety form and the App Store privacy labels, so doing it once saves effort in three places.
Walk through each screen of the app and each SDK in the build. Ask what leaves the device. Run the app through a network proxy on a test device if you can. Your policy is only as accurate as this step.
The sections to include
Who you are and how to reach you
State the name of the publisher responsible for the app and give a working contact address, such as a monitored mailbox on your own domain. Users must be able to reach a real person with privacy questions. Use an address you actually read, and say how long you usually take to reply only if you can keep that promise.
What data you collect
List the categories in words a user would recognise. Separate the following groups:
- Information the user provides, such as an email address, profile details, or content they create.
- Information collected automatically, such as device model, operating system version, app version, language, and approximate location derived from network data if applicable.
- Identifiers, such as an advertising ID or an installation ID.
- Diagnostic data, such as crash reports and performance metrics.
- Information from permissions the user grants, such as contacts, camera, or microphone, and what you do with it.
Say what you do not collect only when you are sure. A false “we never collect X” is worse than silence.
Why you collect it
Tie each category to a purpose: providing the feature, keeping the account secure, understanding usage, fixing crashes, showing ads, or complying with law. Purposes should be specific. “To improve our services” alone tells the reader nothing.
Who you share it with
Name the types of recipients: hosting providers, analytics providers, crash reporting providers, advertising networks, payment processors, and authorities when legally required. If you can, name the providers and link to their own policies. Distinguish between service providers that act on your instructions and parties that use data for their own purposes, such as many advertising networks. Say clearly whether you sell data or share it for advertising, in the terms the relevant law uses, and check which terms apply to your audience.
How long you keep it
State retention periods in concrete terms for each category, or the criteria used to decide. For example, account data is kept while the account exists and deleted within a stated period after closure. Do not invent a period you do not follow. If backups delay deletion, say so.
How you protect it
Describe protections honestly and without absolute claims. Mention encryption in transit and access controls if they are true. Avoid promising “complete security” because no one can guarantee it.
Children
If your app is not aimed at children, say so and explain what you do if you learn a child has provided data. If it is aimed at children or has a mixed audience, the rules are stricter and vary by region and by store programme. Read the family and children policies in Play Console and App Store Connect, and get professional advice. Do not guess.
User rights and choices
Explain what users can do: view or export their data, correct it, delete it, withdraw consent, opt out of personalised ads through device settings, and revoke permissions. Describe how to make a request and how it is verified. If you let people delete their account in the app, say where. The rights that legally apply depend on where your users live, so confirm this with a professional rather than copying a list.
International transfers
If your service providers process data in other countries, say so and describe the safeguards you rely on, if any apply. Again, the mechanics depend on the law, so verify them.
Changes to the policy
Say how you will announce changes, for example by updating the date at the top and notifying users in the app for significant changes. Then do it. Keep an archive of old versions, because disputes sometimes turn on what a policy said at a given time.
Plain-language writing tips
- Use short sentences and everyday words. Define any term you cannot avoid.
- Put a summary at the top that fits on one screen of a phone.
- Use headings that match the questions people ask, such as “What we collect” and “How to delete your data”.
- Prefer lists to dense paragraphs for categories of data.
- Avoid both vagueness (“may collect certain information”) and excessive hedging.
- Write in the present tense about what the app does today, not what it might do someday.
- Show the date of the last update prominently.
Hosting the policy on a stable URL
Store listings, in-app links, and ad network settings all point at your policy, so a broken link is a real problem.
- Host it on a domain you control, not on a temporary page builder or document share link.
- Choose a short, permanent path such as a dedicated policy page for each app, and never change it. If you must move the page, set up a permanent redirect.
- Make the page readable without scripts, without a login, and on a small screen.
- Serve it over a secure connection.
- Link the same address in the store listing, inside the app, and on your developer website. A consistent address also supports ad verification such as app-ads.txt, which relies on a credible developer site.
- Monitor the URL. A check that fails when the page returns an error is cheap insurance, and the portfolio checklist covers monitoring many apps at once.
Keep it in step with the product
A policy ages the moment you add an SDK, a permission, or a feature. Tie updates to your release process: when the dependency list or the permission list changes, the policy, the store forms, and the in-app disclosures change in the same pull request or the same checklist. Sensitive apps, for example in health or cycle tracking, should be reviewed more often; see the cycle tracking privacy checklist for concrete habits.
What a policy cannot do
A policy does not make questionable practices acceptable. If your app collects more than it needs, the fix is to collect less, not to describe it more elaborately. Stores also compare the policy with the forms you submit and with observed behaviour. For further articles on running apps responsibly, see the publishers hub.
Final review checklist
- Every data category in the inventory appears in the policy.
- Every SDK and recipient type is covered.
- Retention and deletion statements match real processes.
- The contact address works, and someone reads it.
- The URL is stable, public, and mobile friendly.
- A qualified reviewer has seen it where the law requires it.