Privacy Policy URL for App Store and Play

An app privacy policy is a page that says who you are and what the app does with people’s information. Stores ask for the URL. Review compares that page to the forms you filled in. If the page names an analytics SDK you removed, or the form says you collect contacts while the page says you collect nothing, you are describing two different apps. Fix the words before you submit.

On the App Store, the privacy policy URL is required for iOS and macOS apps. How that label works is app privacy details. On Play, the matching form is the Data safety form. The support URL is a different field, covered in App Store support URL. Apple’s product page overview is Creating Your Product Page .

The page has to name you

Write the legal name of the developer or the company that sells the app, and the contact address a person can use. “We” with no name is not a policy. If you are a solo developer, use your name or the name on the developer account, consistently. The same name should appear on the App Store and on Play. A template that still says a generator company’s name is not your policy.

Say how to reach you about privacy, not only about a crashed screen. An email on the policy is enough if you read it. Point the App Store privacy policy URL at this page. Do not point it at the support homepage unless that homepage is the policy. Both URLs have to load. Test them logged out.

Sections to write

Write these sections in your own words. Who operates the app. What the app is. What you collect, in a list a user can check against the screens they see. Why you collect each item. Who else receives it, such as a host or an analytics provider you actually use. How long you keep it, or how a user can ask you to delete an account. How to contact you. If you do not sell data, say that in a plain sentence rather than a paragraph of legal theater you do not understand.

If a section does not apply, omit it or say it does not apply. Do not leave a heading about advertising IDs in an app that has no ads. Do not leave a heading about precise location if you never request location. Extra headings are how templates accuse you of collection you do not do.

Worked example: accounts and optional analytics

The app creates an account with an email and a password. The email is used to sign in and to send a password reset. That is collection, and the policy should say so. There is no contact upload and no photo library access. Optional analytics can be turned off in settings. When it is on, it sends crash traces and a count of a feature being opened, through one SDK you can name. When it is off, that SDK does not receive those events. Write both states.

Do not write “we may collect various data to improve your experience.” Name the email, name the crash trace, name the provider, and name the off switch. If payments are handled by Apple or Google and you do not see card numbers, say that you do not receive card numbers, and do not claim you store them. If you later add a second SDK, update the policy and both forms in the same release.

The policy, the App Privacy label, and the Play Data safety form should list the same email, the same optional analytics, and no SDKs you already removed.

Match the nutrition label and Data safety

App Privacy in App Store Connect is the nutrition label shoppers see. Data safety on Play is the form shoppers see there. Neither is replaced by the policy URL. They have to agree with it. If the label says “data not collected” and the policy describes an account email, the label is wrong or the policy is. Pick the truth of the binary and make both say it.

Optional analytics is a common mismatch. If the SDK is in the binary and sends data before the user finds the switch, you collect that data. Say so. If the switch defaults to off and nothing is sent until it is on, you can say it is optional, and the form should still disclose the data that is sent when it is on. Read the form’s own definitions. Do not guess that “optional” means “omit.”

A wrong SDK name gets you rejected

Templates love a long vendor list. Your binary has a short one. If you copied a policy that mentions an ad network, a social login, or a crash tool you do not link, delete those sentences. If review or a later audit compares the policy to the app, the extra names look like hidden collection or like carelessness. Both are bad. The missing name is just as bad: an SDK that runs and is not mentioned.

When you remove a vendor, update the policy, the nutrition label, and Data safety together. Shipping the binary first and “fixing the policy next week” leaves a window where the public page is false. The URL can stay stable. The words on it should change the day the collection changes.

Where the URL has to live

On the App Store, paste the policy URL into the privacy policy field. It is required for iOS and macOS. A tvOS app also needs the policy text in the Apple TV privacy field. On Play, add the privacy policy URL in the store listing where Play Console asks for it, and keep Data safety aligned. The page should be public. A PDF behind a login, or a Google Doc set to private, is not a policy users can read.

Link the policy from the support page and from inside the app, near the account screen, so the URL in the store is the same URL in the product. One policy for both stores is fine if both stores’ forms match it. Two policies that drifted apart are worse than one careful page. Content rating questionnaires are a different form. Do not stuff age-rating answers into the privacy page to avoid filling them out.