App Privacy Policy Checklist: What to Include Before Launch
Here I'll walk you through an app privacy policy checklist to make sure your policy matches your app before you submit it.

A privacy policy is a terrible place for plot twists, especially ones a store reviewer finds first. This mobile app privacy policy checklist helps iOS and Android developers document what the release build does. It also helps you write a matching policy and match the answers in Apple’s and Google’s consoles. It is not a fill-in-the-blanks legal document. It is release work that keeps your policy, app behavior, and store listing consistent.
Treat it as a three-way check: the shipped app, the public policy, and the store disclosure. If an analytics SDK sends a device identifier but the policy says “we collect nothing,” friendlier wording will not fix it. The policy needs to catch up with the app.
Start with a data inventory, not a template
Start with the release build, then work outward. A template can give you headings, but it cannot know which SDKs, APIs, backend jobs, and support tools your app uses. Think of the inventory as your app’s packing list, except the socks are crash reports.
For each data type, write down:
- What the data is, such as email address, location, purchase history, crash log, or device identifier.
- Where it comes from: a form, a permission, automatic collection, or a third-party SDK.
- Why the app uses it.
- Who receives it, including your processors and outside partners.
- How long you keep it and what starts deletion.
- Whether a user can refuse collection, delete an account, or make another privacy request.
Audit the app, backend, and every third-party SDK
Read your dependency list, SDK documentation, backend configuration, analytics dashboard, payment provider settings, and web content your app controls. Apple requires App Privacy answers to include third-party partners whose code you add. Google Play also requires Data safety declarations to cover data handled through third-party libraries and SDKs. A quiet SDK is still part of your app’s privacy story.
For Apple’s disclosure questions, collection means data sent off the device that you or a third party can access beyond the time needed to handle a request. Google Play’s Data safety form has its own definitions of collection and sharing, including data sent by SDKs. Read each store’s definitions as you fill in its form. Do not assume the labels mean the same thing everywhere.
The policy should describe the release build you ship, not the product story you meant to build three sprints ago.
App privacy policy checklist: what the policy needs to say
Use plain headings and include the facts a person needs to understand your data practices. Apple’s App Review Guidelines 5.1.1 require a privacy policy that clearly explains what data you collect, how you collect and use it, which third parties can access it, and your retention, deletion, and consent-withdrawal practices.
Use this as a content checklist:
- Who operates the app and how to contact them. Name the developer or company and provide a real contact method for privacy questions.
- Data you access or collect. Include data from forms, permissions, device signals, account creation, and SDKs. Do not hide behind “may collect” when the release build does collect it.
- How and why you use it. Connect every category to a purpose, such as sign-in, feature delivery, fraud prevention, support, analytics, or advertising.
- Sharing and service providers. Say who receives data and why. A payment processor, crash-reporting provider, cloud host, ad network, and analytics service may each have different roles.
- Retention and deletion. Explain how long data is kept, what you delete after an account-deletion request, and any data you must keep for security, fraud prevention, or law.
- Choices, rights, and consent. Tell users how to change preferences, withdraw consent where that applies, request deletion, or make other privacy requests.
- Security description. Describe the safeguards you actually use at an appropriate level. “We protect your data” is not a useful explanation on its own.
Keep the policy readable, but do not use it instead of a permission prompt or consent screen. If Android policy requires a prominent in-app disclosure and consent for unexpected sensitive-data access, Google says the disclosure must appear during normal use before the permission or consent request. A link buried in a policy does not do that job.
Check the three common data scenarios
Analytics and crash reporting
It is easy to file analytics and crash reporting under “technical stuff,” then forget them in your disclosure. Do not. Record what the provider receives, whether it receives identifiers, which events or diagnostics leave the device, why, and how long they are kept. Apple says data collected only for analytics or app functionality may still need to be declared in App Privacy.
Check the provider’s current documentation and your configuration. Disabling ad features, IP storage, user-ID linking, or a diagnostic module can change the right answer. Configuration affects behavior, so it belongs on the release checklist too.
Advertising and tracking
List every ad network, attribution tool, and audience feature. Apple calls data use “tracking” when data about a person or device from your app is linked to third-party data for targeted ads or advertising measurement, or shared with a data broker. Its App Privacy Details guidance explains more.
Do not call all analytics “tracking,” but do not assume an SDK is harmless because you only use one feature. Ask the provider what it collects from your app and whether it combines data across apps or sites. Then make sure your policy, consent flow, and App Privacy answers match that answer.
Payments and subscriptions
Describe the purchase information your app receives and why. Apple notes that payment information entered outside your app through a payment service that you never access is not collected by you for its App Privacy answers. That does not erase the rest of your purchase flow: account IDs, purchase history, subscription status, receipts, and support records may still be data you handle.
State which provider processes payments, what your app stores, and where a person can ask about deletion or retention. Keep the wording specific to your setup. “We use a payment provider” tells readers very little.
Meet Apple’s app privacy requirements
Apple needs two related but separate items: a public policy and App Privacy disclosures. In App Store Connect, open your app, choose App Privacy, and enter the privacy-policy URL. Apple says a URL is required for iOS and macOS, while its User Privacy Choices URL is optional. App Privacy also asks whether you or third-party partners collect data, the data types and purposes, whether data is linked to a user, and tracking.
Follow this short Apple check:
- Put the policy on a public web page and make it reachable inside the app.
- In App Store Connect, open App Privacy and declare the data collected by your app and integrated partners.
- Review the Product Page Preview before publishing the responses.
- Update the disclosures when the app’s data practices change. Apple says you can update them without submitting a new app version.
Do not mix up App Privacy and an Apple Privacy Manifest. App Privacy is the store disclosure customers see. A Privacy Manifest is a separate development file that describes certain SDK privacy practices and required-reason API use. One does not replace the other.
Meet Google Play’s privacy requirements
Google Play requires a privacy policy for every app. The User Data policy says you must link it in Play Console and make it accessible from the app. The URL must be active, public, non-geofenced, non-editable, and not a PDF. “Non-editable” means users cannot change the page. You can still update your policy.
In Play Console, complete the Data safety form on the App content page. Google says all published apps must complete it, including apps that collect no user data. Those apps can declare that no data is collected or shared, but they still need a privacy-policy link. The form covers your app and third-party SDKs, so return to your inventory before picking answers.
If your app lets users create an account, Google also requires an in-app way to request account deletion and a web page where users can request deletion of their account and related data. The account deletion guidance says the page must load, clearly relate to the app or developer name, and make the deletion path easy to find. Explain any lawful retention and why it applies in your policy.
Your policy, App Privacy answers, and Data safety answers should be three descriptions of the same app.
Run a pre-launch consistency check
Do this after you have a real release-candidate build. It catches changes from a late SDK update, a new sign-in method, or a “small” dashboard switch. Release week has a funny definition of “small.”
- Test the public policy URL while signed out. Check it on mobile data and from a location where your customers can reach it. Confirm it is a web page, not a PDF or editable document.
- Open the in-app policy link on every supported platform. It should lead to the current policy without a dead end or a login wall.
- Compare each SDK with the policy and store forms. For every inventory row, compare the app’s behavior, the policy language, Apple App Privacy answers, and Google Data safety answers.
- Test account deletion where accounts exist. Confirm the in-app route works, the web route is discoverable, and your support team can handle the request.
- Update all three items when data practices change. A new SDK, provider setting, permission, or backend event can require updates to the app, policy, and store disclosures.
FAQ
Does every app need an app privacy policy?
Apple requires a privacy-policy URL for iOS apps in App Store Connect. Google Play requires every app to add a policy link and complete Data safety, even when the app does not collect user data. Privacy laws may add requirements based on where you operate and who uses the app. Make the policy match your real data practices and get legal advice when needed.
Do analytics SDKs count as data collection?
They can. Apple and Google both require developers to account for third-party SDK data practices in their store disclosures. Check what the SDK sends off-device, who receives it, how it is used, and whether identifiers or user data are involved.
Is a privacy policy the same as Apple’s Privacy Manifest?
No. The public privacy policy explains your data practices to users. App Privacy is Apple’s store disclosure. A Privacy Manifest is a separate development artifact for certain SDK privacy practices and required-reason API use.
Can my policy be a PDF?
Not for Google Play. Google’s User Data policy requires a public, active, non-geofenced, non-editable URL and specifically says it cannot be a PDF. Use a regular web page, then link to that same current policy in the app.
What must an account-deletion page say?
For Google Play apps that support account creation, the web resource needs a clear, working path to request account and associated-data deletion, identify the app or developer, and explain additional steps such as subscription cancellation. Say what data you retain, why, and for how long when retention applies.
Conclusion
Start with the data inventory, then write the policy from it. Use the same inventory to fill in App Privacy and Data safety, test the public and in-app links, and revisit all three when your data practices change. That work will not guarantee a store approval, but it gives reviewers and users a clear, accurate account of what your app does.
Further reading: How to add a privacy policy app screen and the App Review Guidelines checklist.
Keep Reading
App Tracking Transparency Explained for App Founders
App Tracking Transparency explained for app founders: learn when ATT applies, how Apple’s permission prompt works, and how to avoid common review mistakes.

App Privacy Policy Generator Comparison: What Tools Cover
Compare app privacy policy generators by SDK prompts, hosting, editing, Apple App Privacy, Google Data safety, and account deletion support.