How to make a privacy policy for an app

Open the app’s permission configuration, backend routes, and integration settings. For each feature, record the data it accesses, whether that data stays on the device or leaves it, and which service receives it. Include background activity and default SDK settings, not just the information users type into visible fields.

Work through it feature by feature:

• Permissions: camera, microphone, photos, contacts, precise or approximate location, Bluetooth, notifications, health data, and anything else the operating system asks the user to allow.
• Data users type in: names, email addresses, profile photos, messages, support requests, payment details, free-form notes.
• Data generated automatically: device identifiers, IP addresses, app interactions, crash logs, performance traces, push tokens.
• Data from elsewhere: sign-in providers, payment processors, partners, or your own website.

For each item, note whether it stays on the device or is sent to a server. Both stores treat data that is only processed locally as not collected: Apple says data processed only on device is not “collected”, and Google says on-device processing does not need to be disclosed in Data safety. That distinction matters later, so record it now. Then note the purpose, the recipient, and how long you keep it.

Here is the short version: you cannot publish on the two biggest app stores without one. Google Play's User Data policy says every app must post a privacy policy link in the designated Play Console field and inside the app, and it states that apps that do not access any personal and sensitive user data must still submit a privacy policy. Apple's App Review Guidelines require a privacy policy link in App Store Connect and within the app.

Store rules are only half the story. Privacy laws such as the EU and UK GDPR require you to tell people what you do with their personal data at the moment you collect it, and California's CalOPPA requires commercial online services that collect personally identifiable information from California residents to post a privacy policy. If your app has users in several regions, several of these rules can apply at once.

The good news is that one accurate, well-structured document can serve the stores and the laws together. If you are still unsure whether your project is covered, start with do I need a privacy policy?, and if your app truly sends nothing off the device, read the guide to privacy policies for apps that collect no data.

This is where most app privacy policies go wrong. Google states that data collected by the libraries and SDKs in your app must be reflected in your Data safety form, whether the data goes to your servers or a third party's. Apple's App Privacy details likewise require you to include the practices of third-party partners whose code you integrate.

List every dependency that can talk to the network and check its documentation:

• Analytics such as Firebase Analytics or similar event trackers
• Crash reporting and performance monitoring
• Advertising and mediation SDKs, which often use advertising identifiers
• Attribution and deep-linking tools that measure install campaigns
• Authentication providers like Sign in with Apple or Google Sign-In
• Payments, subscriptions, push notifications, chat, and customer support widgets

Many providers publish dedicated store disclosure pages; Google also points developers to the Play SDK Index. Our Firebase privacy disclosures and analytics privacy disclosures guides show what typically needs to be named. Remove SDKs you no longer use: every dormant library is a disclosure you have to keep accurate.

Once the map is done, the structure almost writes itself. Google Play's User Data policy expects developer information and a privacy point of contact, the types of personal and sensitive data accessed, collected, used, and shared, secure data handling, and a retention and deletion policy, all clearly labeled as a privacy policy. Apple's guideline 5.1.1(i) asks for what you collect, how, all uses, confirmation that third parties provide equal protection, retention and deletion, and how users can revoke consent or request deletion.

A practical outline looks like this:

1. Who you are, the app name, and how to contact you about privacy
2. The data you collect, grouped by source
3. Why you use each category, with legal bases where GDPR applies
4. Who receives data, including named SDK providers and processors
5. How long you keep data and how deletion works
6. User rights and how to exercise them
7. Children, international transfers, and security
8. How you announce changes, plus an effective date

For a full checklist with explanations, see what a privacy policy should include.

Reviewers and users compare your policy with your store declarations, so treat them as one set of documents. On Google Play, every developer must complete the Data safety form, and a privacy policy is required to finish it. On the App Store, you answer App Privacy questions about data types, whether each is linked to the user, and whether it is used for tracking.

Two definitions keep these aligned:

• Apple says “collect” means transmitting data off the device in a way that lets you or your partners access it for longer than needed to service the request in real time.
• Google says data processed ephemerally, held only in memory for a real-time request, must still be included in the form, but may not be shown on the listing.

A weather app that sends location to fetch a forecast and keeps nothing is a classic example. Your policy can still mention that location is sent to a weather provider to answer the request, which is honest and consistent with both labels.

Whenever a release adds a data type or SDK, update the policy, Data safety, and App Privacy answers together. The Google Play privacy policy generator and Apple App Store privacy policy generator pages walk through the store-specific fields.

If people can create an account in your app, both stores expect them to be able to get rid of it.

Google Play requires apps that allow account creation to let users request deletion from within the app and through a web link that works without reinstalling the app, which you enter in Play Console. Google's User Data policy adds that when you delete an account at a user's request, you must also delete the associated user data, with limited exceptions such as security, fraud prevention, or legal obligations. Apple's guideline 5.1.1(v) says apps that support account creation must also offer account deletion within the app.

Your privacy policy should tell users:

• where the deletion option is, in the app and on the web
• what is deleted and how quickly
• what you keep, such as purchase records required for tax law, and why
• how deletion affects data held by processors

Do not promise instant deletion if backups keep data for 30 days; describe the real timeline. The Google Play privacy policy guide covers the Play Console deletion fields in more detail.

A privacy policy that nobody can open does not count. Google Play requires the policy to be available on an active, publicly accessible and non-geofenced URL, with no PDFs, and it must be non-editable. Apple asks for a publicly accessible privacy policy URL in App Store Connect.

Inside the app, put the link where people actually look:

• the settings, about, or account screen
• the sign-up or onboarding screen, next to the consent checkbox if you have one
• near permission explanations for sensitive features

Keep in mind that a link in the policy is not a substitute for a just-in-time notice. Google's prominent disclosure rules say that when your app collects personal and sensitive data in ways users might not expect, the disclosure must appear in the app during normal use and cannot only be placed in a privacy policy.

If you do not have a website yet, our guide on how to get a privacy policy URL compares your hosting options and shows how to test the link before you submit.

Privacy laws follow your users, not your office. A solo developer in Prague with players in Texas and Toronto can be subject to several regimes at once. The most common for apps:

• EU GDPR and UK GDPR when you offer the app to people in Europe or the UK, with detailed transparency duties and user rights
• California CCPA and CPRA for businesses that meet the statutory thresholds, plus CalOPPA, which requires a posted policy from online services that collect personal information from California residents
• Other US state privacy laws with their own thresholds and rights
• COPPA if your app is directed to children under 13 or you know you collect data from them
• Brazil's LGPD, Canada's PIPEDA, Australia's Privacy Act, and New Zealand's Privacy Act 2020

You do not need to become an expert in all of them. You need to know which ones are plausible for your audience and make sure the policy covers their required disclosures. Our privacy law guides summarize what each one asks a privacy policy to say, starting with the GDPR privacy policy guide and the CCPA and CPRA guide.

If you would rather answer questions than draft from a blank page, the app privacy policy generator turns your data map into a document. You choose the application use case, then answer plain-language questions about accounts, permissions, SDK providers, payments, deletion, children, and the regions you serve.

How it works, in practice:

• No AI writes your clauses at runtime. Clauses come from a versioned library and are selected deterministically from your answers, so the same answers produce the same policy.
• The questionnaire and full preview are free, with no account needed, and the simple HTML and PDF download is free.
• Advanced regional or optional modules cost $5, covering the EU and GDPR, the UK, US laws including CCPA and CPRA, CalOPPA, COPPA, and other states, Brazil, Canada, Australia, and New Zealand.
• Optional public hosting adds $0.99 once and gives you a public page to paste into Play Console and App Store Connect.

If you build with an AI coding agent such as Codex, Claude Code, or ChatGPT, the developer MCP server lets the agent inspect your codebase and create a private draft for you to review. A generated policy reflects your answers; it is not legal advice.

Run through this list before every store submission, not just the first one:

• Every permission in the manifest and Info.plist has a purpose described in the policy.
• Every SDK that sends data off the device is named or described, with its purpose.
• The policy, Data safety form, and App Privacy answers list the same data types.
• Advertising identifiers and tracking are described only if you actually use them.
• Account deletion is available in the app, and on the web for Google Play, and the policy explains it.
• Retention periods are real, including backups and logs.
• Children are addressed: either the app is not directed to them, or the children's sections are complete and reviewed.
• Contact details, the developer name shown on the store listing, and the effective date are current.
• The URL opens on a phone, signed out, without a PDF download or a redirect to your homepage.
• The policy is linked inside the app where users can find it.

Privacy policies drift as apps grow, so schedule a review whenever you add a feature that touches data. Our guide on how often to update a privacy policy suggests practical triggers.