A privacy policy is required for every app on both the App Store and Google Play. That requirement is widely known. What's less widely understood is what makes a privacy policy actually pass review — as opposed to technically existing but still causing a rejection.
The bar isn't high. But it is specific. Here's what you need to cover and the mistakes that cause this step to fail.
What Both Platforms Require
Both the App Store and Google Play require your privacy policy to cover: what data you collect, why you collect it, who you share it with, how long you keep it, user rights over their data, and a contact method for privacy inquiries.
The most important word is accurate. A policy copied from a template that doesn't reflect your app's actual data practices is not a valid privacy policy for review purposes — even if it sounds comprehensive.
Review teams check for alignment between your policy and your app's real behavior. If your app uses Firebase Authentication and your policy says "we do not collect personal information," that's a contradiction. If your app targets adults but your policy has a COPPA section for children, that's a signal something was generated without thought.
The Most Common Failure Points
Policy Written for a Website, Not a Mobile App
Many founders grab a website privacy policy template and link to it from their app submission. Website policies often cover cookies and browser tracking — not mobile-specific items like device identifiers, push notification tokens, location access, or health data. If your policy doesn't mention these categories and your app touches any of them, it's incomplete.
"We Don't Collect Any Data" When You Clearly Do
Any app that requires account creation collects personal data. Any app that uses analytics collects usage data. Any app that uses crash reporting collects device information. Writing "we collect no personal data" and then having the user sign up with an email address is an immediate mismatch.
Be honest and specific. It's not a liability to say you collect data — it's a requirement to disclose it accurately.
Third-Party SDKs Not Mentioned
Your app doesn't have to do the data collection directly for it to count as data collection. If Firebase is in your app, Firebase collects data. If Mixpanel, Amplitude, or any similar analytics tool is running, it collects data. If you use an AI API, queries may be logged by that provider.
Every SDK you use that collects data needs to appear in your privacy policy. List the service, what it collects, and link to its own privacy policy. This is also required in Google's Data Safety form.
Policy URL Is Not Live at Submission Time
The URL must be reachable from an incognito browser window with no login and no redirect. Test it. Submitting with a URL that produces a 404, a login wall, or a "coming soon" page is an immediate rejection — not a warning, a rejection.
What to Actually Write
A valid mobile app privacy policy doesn't need to be long. It needs to be accurate. Here's the structure that covers the requirements for most apps:
- What data we collect — list each data type: name, email, device ID, location, usage events, etc.
- Why we collect it — for each type, state the specific purpose: authentication, analytics, personalization, crash reporting
- Who we share it with — list every third-party service that receives user data, with a link to their own privacy policy
- How long we keep it — state your retention period or the criteria used to determine it
- Your rights — explain how users can request access, correction, or deletion of their data
- Contact information — an email address for privacy-related inquiries
For apps in the EU, US (California), or targeting children, there are additional requirements — GDPR, CCPA, and COPPA respectively. These add sections but don't change the fundamental structure above.
Tools That Can Help
Several tools generate privacy policy drafts based on your app's actual features: Termly, iubenda, and GetTerms are commonly used. These are starting points, not final outputs — review the generated policy against your app's actual behavior before publishing it.
The test: give the policy to someone who hasn't seen your app and ask them if they can understand what data the app collects and why. If they can't, the policy isn't clear enough for review.
Where to Host It
The policy needs a stable, permanent URL. Options that work: a dedicated page on your website, a simple hosted page through your domain provider, or a privacy policy on a service like Notion or a static site — as long as the URL doesn't change and the page loads publicly.
Options that don't work: a Google Doc with restricted sharing, a PDF that requires download, a page that redirects to your home page, or any URL that contains expiry tokens.
Keeping It Current
Your privacy policy is a living document. Every time you add a new SDK, integrate a new service, or change what data you collect, the policy needs to be updated before the next app update is submitted. A policy that was accurate at launch but doesn't reflect a Firebase integration you added six months later is a compliance problem waiting to be found in review.
