Writing your app's privacy policy with an AI assistant — a prompt that works

An AI assistant will write a privacy policy in ten seconds. The problem is what it writes it from. Asked “write a privacy policy for my fitness app”, it has nothing but the word “fitness”, so it produces the average of every privacy policy it has read: clauses about cookies your app does not set, advertising identifiers for an app with no ads, a retention period of “as long as necessary”, and none of the SDKs you actually ship. It reads well. It is also the part a store reviewer compares against your Data safety form and App Privacy answers, and that comparison is where it fails.

Why the one-line prompt fails

• It invents. A model asked to fill a section fills it. A retention period, a legal basis, a company address — each one plausible, each one a statement about your business you did not make.
• It is generic where it has to be specific. The section that matters most is the list of third-party services, and a model that has not seen your dependency file cannot name them.
• It over-declares. Listing data you do not collect is not “safe”. It is a mismatch with your own store declarations, which is the same problem in the other direction.
• It formats for the chat window. Tables, footnotes and inline HTML look fine in the reply and arrive broken wherever you paste them.

What a prompt has to make it do

1. Read evidence first. A coding agent opened in your repository — Claude Code, Cursor, Codex and the like — can read build.gradle, Podfile.lock, Info.plist and the manifest, and list every SDK and permission with the file it came from. That list is the substance of the policy. A chat assistant without file access should be told to ask you to paste those files.
2. Stay out of everything else. Build and manifest files are enough. There is no reason for it to open .env files, keystores or source code, and a prompt that says so is one less thing to worry about.
3. Ask only what cannot be read. How long you keep data, whether there is a backend, whether the app is aimed at children, whether you share data with a partner that leaves no trace in the build. Nothing else needs asking.
4. Refuse to guess. Where you do not know, it writes [confirm: …] instead of a sentence. A visible gap is fixable; an invented clause is a published statement.
5. Write for where it will be published. Plain Markdown, links only where they are useful — the providers’ own privacy pages, your support address — and the disclaimer that the text is not legal advice.

The prompt

Copy it whole. Replace the bracketed facts at the top, or leave them and let the assistant ask.

You are helping me write the privacy policy for my mobile app. It will be published as a web page on AppFoyer and its URL goes into the "Privacy policy" field of Google Play and App Store Connect, where reviewers compare it with what the app actually does. Accuracy matters more than length.

## About the app

- App name: [app name]
- Developer / company: [developer or company name]
- Support email: [support email]
- Platforms: [Android, iOS or both]
- Store listings: [store listing URLs, or "not listed yet"]
- Where this policy will be published: [your AppFoyer site URL]/privacy
- What the app collects, as I declared it: [what the app collects — e.g. account info, analytics, ads, crash reports, location, purchases, or nothing]
- Account deletion page: [your AppFoyer site URL]/account-deletion (only if the app has user accounts)
- Country whose law applies: [country, if you have one]

## Step 1 — find the facts

If you can read this app's source code, read only its build, manifest and store-metadata files — for example `build.gradle(.kts)`, `gradle/libs.versions.toml`, `AndroidManifest.xml`, `Podfile.lock`, `Package.swift`, `Info.plist`, `PrivacyInfo.xcprivacy`, `pubspec.yaml`, `package.json`, `app.json`. Do not open `.env` files, keystores, credentials or any other secrets, and do not change any file.

From them, list:

- every third-party SDK or service that collects or receives user data (analytics, ads, crash reporting, sign-in, payments, push notifications, backend, AI APIs) and what it receives;
- every permission the app requests and the feature that uses it;
- whether the app sells in-app purchases or subscriptions (StoreKit, Google Play Billing, RevenueCat and the like).

Show me that list with the file each fact came from, point out anything that contradicts what I declared above, and ask me to confirm it.

If you cannot read the code, ask me to paste the dependency files (for example `app/build.gradle` and `Podfile`) or to list the SDKs and permissions myself.

## Step 2 — ask only what you cannot know

Then ask me, in one short numbered list, and wait for my answers:

1. How long each kind of data is kept, and whether there is a backend (where it runs, what it stores).
2. Whether the app is directed at children under 13.
3. Whether any data is shared with or sold to anyone beyond the services above.
4. Whether the app takes any payments, if the files did not settle it.
5. Anything else you could not determine.

Never guess. Where I do not know an answer, write `[confirm: …]` in the text instead of inventing one.

## Step 3 — write the policy

Sections, in this order, leaving out any that do not apply: Data we collect · How we use it · Third-party services · Purchases and subscriptions · Permissions · Data retention and deletion · Children · Your choices and rights · Changes to this policy · Contact.

- Plain language, short sentences. Describe what this app does; no clauses about things it does not do.
- Under Third-party services, name each provider, say what it receives and why, and link its own privacy policy page.
- Do not invent retention periods, legal bases, company addresses or a data protection officer — use `[confirm: …]`.
- Start with `# Privacy Policy`, then the line `_Last updated: [today's date]_`.
- Write these placeholders exactly as shown, never the values — they are filled in from my settings when the page is published: `{{app_name}}`, `{{developer_name}}`, `{{support_email}}`, `{{public_url}}`.
- In the Contact section, write the address as `[{{support_email}}](mailto:{{support_email}})`.
- If the app has user accounts, link account deletion as `[{{public_url}}/account-deletion]({{public_url}}/account-deletion)` in the retention and deletion section.
- Mandatory if the app is on iOS and has any in-app purchase or subscription — declared above, found in the build files or confirmed by me: in the Purchases and subscriptions section, include this sentence unchanged: For the iOS version, Apple's standard [Licensed Application End User License Agreement](https://www.apple.com/legal/internet-services/itunes/dev/stdeula/) applies to your use of the App. Never leave it out when the app takes payments.
- End with this paragraph, unchanged:

  _This page was generated from a template provided by the hosting platform and completed by the app developer. It is not legal advice. The developer named above is solely responsible for its accuracy and for complying with the laws that apply to them._

## Format — this is pasted into a Markdown editor

- Reply with the finished policy only, as Markdown inside one ```markdown code block, with nothing before or after it.
- CommonMark only: headings, paragraphs, lists, bold, italics and links. No tables, no HTML, no images, no footnotes.
- Links only to the providers' own privacy policy pages, to `{{public_url}}`, to Apple's EULA as above and to the support email. Any other link is shown as plain text on the published page, so leave it out. No link shorteners, no download links.

It is written for pages published on AppFoyer, which is why it asks for {{app_name}}-style placeholders and ends with our disclaimer. If you publish somewhere else, delete the lines in Step 3 about placeholders, the deletion link and the closing paragraph, and ask for the values instead.

Before you publish what it wrote

The assistant drafted it; you are the one publishing it. Check, in this order:

• Every SDK in your dependency file appears in the policy, and nothing appears that is not there. This is the mechanical test and the one reviewers effectively run.
• Every [confirm: …] is replaced with a real answer, or the sentence is removed.
• The third-party section matches your Data safety form and App Privacy answers. If they disagree, one of them is wrong — fix it, whichever it is.
• If the app takes payments, Apple’s EULA link is there. An iOS app with in-app purchases or subscriptions links Apple’s standard Licensed Application End User License Agreement from its privacy policy; the prompt asks for it, so check it survived.
• The retention periods are yours. Only you know what your backend keeps and for how long.
• Anything unusual goes to a lawyer. Health data, finance, children, or data shared with a partner — a prompt does not change what a template cannot cover.

What AppFoyer does here

The privacy page editor in the dashboard has a Write it with your own AI panel: the same prompt, already filled in with your app’s name, developer, support email, platforms, store links and the data you declared. Copy it, run it in whatever assistant you use, and paste the reply back into the panel — the Markdown is taken out of its code block and put in the editor, where the preview shows exactly what will be published. Nothing goes public until you click publish, and the text passes the same automated checks as any other edit.

The terms page has the same panel with its own prompt — printed in Does your app need a terms of service?. If you use Claude Code, the AppFoyer plugin does the same job for all five pages without copy and paste, and it cannot publish either. Neither route is legal advice, and every page says so.

The authoritative sources

• Privacy policy requirements — Google Play Help
• Provide information for Google Play’s Data safety section — Google Play Console Help, on SDK data being yours to declare
• App privacy details on the App Store — Apple