app store
Do I Need a Privacy Policy If My App Collects No Data?
Yes, on both the App Store and Google Play. What each store says, the SDK traps that break a no-data claim, and what a short honest policy should say.
By Kyle Hurst ·
A calculator, a flashlight, a timer that keeps everything on the phone: it seems like an app with nothing to disclose shouldn’t need a privacy policy. It does. Apple’s App Review Guideline 5.1.1(i) says “All apps must include a link to their privacy policy,” and Google Play’s User Data policy says “apps that do not access any personal and sensitive user data must still submit a privacy policy.” The good news is that the policy for a genuinely no-data app is short. The bad news is that plenty of apps that “collect nothing” actually collect quite a bit through the SDKs inside them.
This post covers exactly what each store requires, how to check whether your app really collects nothing, what the policy should say, and where to host it.
What Apple requires
Guideline 5.1.1(i) in the App Review Guidelines is not limited to apps that handle personal data:
All apps must include a link to their privacy policy in the App Store Connect metadata field and within the app in an easily accessible manner.
That’s two links, not one. The App Store Connect field alone isn’t enough; the policy also has to be reachable inside the app, typically from a Settings or About screen. A missing in-app link is one of the 5.1.1 rejections covered in our App Store rejection guide.
The guideline then says what the policy must do. Notice the wording of the first point:
- “Identify what data, if any, the app/service collects, how it collects that data, and all uses of that data.”
- Confirm that any third party you share user data with will provide “the same or equal protection.”
- “Explain its data retention/deletion policies and describe how a user can revoke consent and/or request deletion of the user’s data.”
“If any” is Apple acknowledging that the answer can be “none.” A no-data policy is fine. It just has to exist and say so.
App Store Connect enforces this too. Apple’s App information reference lists the Privacy Policy URL as “Required for iOS and macOS apps.” Apple TV apps also need the policy text itself in a separate Apple TV Privacy Policy field. You set the URL under Apps › your app › App Privacy › Privacy Policy › Edit, and Apple’s App Privacy help page notes that “any changes to the URLs releases with your next app version,” so a fixed link won’t go live until your next version ships.
What Google Play requires
Google’s rule is just as broad. The User Data policy says “All apps must post a privacy policy link in the designated field within Play Console,” and the policy must also be linked or included within the app. Then it closes the loophole outright: “Apps that do not access any personal and sensitive user data must still submit a privacy policy.”
You may run into older wording that ties the requirement to sensitive permissions or to apps for children. Google’s Prepare your app for review page still frames it that way, but the same page adds that “even apps that do not access any personal or sensitive user data must still submit a privacy policy.” The current answer is every app. You add the URL under Policy and programs › App content › Privacy Policy in Play Console.
The Data safety form is the other half. Google’s Data safety help page says “All developers that have an app published on Google Play must complete the Data safety form,” with apps only on internal testing exempt. A privacy policy link is required to complete it. For an app that collects nothing, Google says the form and the policy “can indicate that no user data is collected or shared.”
Side by side
| Apple App Store | Google Play | |
|---|---|---|
| Privacy policy required for a no-data app? | Yes, “All apps” (5.1.1(i)) | Yes, “must still submit a privacy policy” |
| Where the store link goes | App Store Connect › App Privacy | Play Console › App content › Privacy Policy |
| Link inside the app too? | Yes, “within the app in an easily accessible manner” | Yes, linked or included within the app |
| URL requirements | ”Publicly accessible” | Active, public, non-geofenced, not a PDF, not editable |
| Privacy questionnaire | App Privacy: answer “No, we do not collect data from this app” | Data safety form, which can say no data is collected or shared |
| What users see | ”Data Not Collected” on the product page | Data safety section showing no data collected or shared |
Does your app actually collect nothing?
Both stores define “collect” the same way, and the definition is narrower than many developers expect, in both directions.
Apple’s App Privacy Details page says “collect” means “transmitting data off the device in a way that allows you and/or your third-party partners to access it for a period longer than what is necessary to service the transmitted request in real time.” Google’s Data safety page says “‘Collect’ means transmitting data from your app off a user’s device.”
What that means in practice:
- Data processed only on the device isn’t collected. Apple says so directly: “Data that is processed only on device is not ‘collected’ and does not need to be disclosed.” Google says the same about on-device processing. An app that saves notes locally, reads the camera to scan a barcode and discards the frame, or does all its math on the phone is in the clear.
- Request data that you don’t keep isn’t collected. Apple’s example: “if an authentication token or IP address is sent on a server call and not retained, or if data is sent to your servers then immediately discarded after servicing the request,” you don’t need to disclose it. Google treats ephemeral processing in a similar way, but it still asks about ephemerally processed data in the form, and data used to build ad or user profiles can never count as ephemeral.
- Data Apple collects isn’t yours to disclose. Apple says “You are not responsible for disclosing data collected by Apple,” naming frameworks such as MapKit, CloudKit, and App Analytics.
Where “collects nothing” usually falls apart is third-party code. Both stores make you answer for every SDK in the build. Apple defines third-party partners as “analytics tools, advertising networks, third-party SDKs, or other external vendors whose code you’ve added to your app,” and says you must identify all data “you or your third-party partners collect.” Google says you “must reflect data collection or sharing carried out by such third-party code in the Data safety form.”
So check your dependencies before you claim nothing:
| If your app includes… | It collects data, because… |
|---|---|
| A crash reporter (Crashlytics, Sentry, Bugsnag) | It sends crash logs and device details off the device. That’s its whole job. |
| An analytics SDK (Firebase Analytics, Mixpanel, PostHog) | It sends usage events and usually an identifier. |
| An ad SDK (AdMob, Meta Audience Network, AppLovin) | It sends identifiers and ad interactions, and on iOS may count as tracking. |
| Firebase as a backend (Auth, Firestore) | User records live on Google’s servers. |
| Push notifications through your own server or a service | You store a push token for the device. |
| Sign-in of any kind | You hold an account record, and account deletion rules kick in. |
Ad SDKs deserve extra care. Apple says an SDK that combines your users’ data with data from other apps for ad targeting counts as tracking “even if you don’t use the SDK for these purposes.” Our Apple privacy labels vs Google Play Data safety guide walks through what common SDKs make you declare on each form, and on iOS, Xcode can generate a privacy report from your SDKs’ privacy manifests to cross-check.
Apple also has an optional-disclosure exception, but it’s narrow. A data type is optional to disclose only if it meets all of these: it isn’t used for tracking; it isn’t used for third-party advertising, your own advertising or marketing, or “Other Purposes”; collection happens “only in infrequent cases that are not part of your app’s primary functionality, and which are optional for the user”; and the user provides it through your interface, knows what’s being sent, has their name or account name prominently shown on the form, and “affirmatively chooses to provide the data for collection each time.” A one-off “send feedback” form might qualify. Anything ongoing does not; Apple adds that “data collected on an ongoing basis after an initial request for permission must be disclosed.”
If you add sign-in later, your policy and labels both change, and so does your deletion obligation. Our account deletion guide covers what each store expects.
What a short, honest policy should say
A policy for a genuinely no-data app doesn’t need to be long, but it still needs to cover what the stores ask for. Google’s User Data policy expects the policy to be clearly labeled as a privacy policy, name the app or developer, give a privacy contact, describe the data accessed, collected, used, and shared, and cover security and retention. Apple’s 5.1.1(i) expects collection, third parties, retention and deletion, and how to revoke consent. For a no-data app, each of those becomes a sentence:
- Title and who you are. “Privacy Policy for [App],” the developer name exactly as it appears on the store listing, and an effective date.
- What you collect. A plain statement that the app doesn’t collect, store, or share personal data, and that anything the user enters stays on their device.
- Third parties. That the app contains no analytics, advertising, or tracking SDKs and shares nothing with third parties. It’s also worth noting that Apple and Google may collect data when someone downloads the app, under their own policies.
- Device permissions. If the app asks for the camera, photos, or location, say what for and that the data stays on the device.
- Retention and deletion. That you keep nothing, so there’s nothing to delete, and that deleting the app removes its local data.
- Children. Whether the app is directed to children.
- Changes and contact. How you’ll update the policy, and an email address that works.
Be precise about “stays on your device.” If the app syncs through iCloud, Apple doesn’t make you declare that CloudKit data, but saying the data never leaves the phone would be wrong. Say it’s stored in the user’s own iCloud account instead. Likewise, if the app downloads content from your server, the request reaches you even if you keep nothing; say what you do with request logs.
The policy has to match your App Privacy answers and your Data safety answers. If all three say “nothing,” you’re consistent. If you later add Crashlytics and forget to update the policy, you’re not.
Where to host it
Apple asks for the URL to your “publicly accessible privacy policy.” Google is more specific: the policy must be “available on an active, publicly accessible and non-geofenced URL (no PDFs),” and it must not be editable.
That rules out a few common shortcuts:
- A PDF, even a public one, fails Google’s rule.
- A page behind a login, or one that’s blocked in some countries.
- An editable shared document, such as a Google Doc anyone with the link can edit.
- A URL that will die, like a free host you’ll forget to renew. A dead link is a 2.1 problem on Apple too, since submissions need “fully functional URLs.”
A static HTML page on your own site, GitHub Pages, Cloudflare Pages, or any static host works. Use the same URL in App Store Connect, Play Console, and the in-app link so there’s one version to keep up to date.
Generate one in a couple of minutes
Our App Privacy Policy Generator has a My app collects nothing button. It clears every data type, SDK, account, and third-party setting while keeping your app name, developer name, and contact details, then writes a short policy. That policy says the app “does not collect, store, or share any personal data” and that what you enter stays on your device. It notes that Apple and Google may collect data at download time under their own policies, states that the app has no third-party analytics, advertising, or tracking SDKs, and covers retention (“We do not keep any personal data”), deletion, security, children, changes, and contact. Its Store cheat sheet tab shows the matching answers: “No” to Apple’s “Do you or your third-party partners collect data from this app?” and “No” to Play’s “Does your app collect or share any of the required user data types?”
A few things to check before you publish. The generated policy keeps Apple’s required “same or equal protection” sentence about third parties and a standard legal-disclosure line even when there are no third parties. Both are harmless; trim them if you like. And if the GDPR section is on, it lists the full set of EU data rights, which is boilerplate for an app that holds no data. Also check the “stays on your device” line against the iCloud and server cases above.
It runs in your browser, and you can download the result as HTML, Markdown, or plain text. Host the HTML, then work through the rest of your release with the App Store submission checklist or the Google Play publishing checklist.