# Privacy policy for an app that collects no data > No-data apps still need an app store privacy policy. See what to write and how to check SDKs, logs, on-device processing, backups, and support emails. Published 2026-10-09 by Jitoma Solutions s.r.o. · 11 min read Yes, an app that collects no data still needs a privacy policy for Google Play and Apple’s App Store. Keep it short and specific: identify the app and developer, explain on-device processing and permissions, and give a privacy contact. Before saying “we collect no data,” check SDKs, logs, backups, and support emails so the statement accurately describes the app and its related services. Canonical URL: https://legalpolicygenerator.com/blog/privacy-policy-for-apps-that-collect-no-data ## Key takeaways - Google Play and Apple require a privacy policy even when your app collects no data, and Google still requires the Data safety form. - Store definitions of “collect” exclude on-device processing, but privacy laws can still treat transient processing as handling personal data. - Crash reporters, analytics, ad SDKs, web views, and support emails are the usual reasons a no-data claim turns out to be false. - A good no-data policy is specific about what stays on the device and honest about the few things that do not. ## What a truthful no-data privacy policy says Write a short policy that distinguishes what happens inside the app from what happens when someone contacts you or uses a connected service. Only make a no-collection statement after checking the app and its dependencies. A local-only feature can stay local while a support inbox separately receives names, email addresses, and messages. Cover these points: 1. **Who you are**: your name or company, the app name, and a privacy contact email. 2. **The core statement**: the app does not collect, store on our servers, or share personal data. 3. **What stays on the device**: settings, files, or content saved locally, and that uninstalling the app removes them, subject to any device backups the user has enabled with Apple or Google. 4. **Permissions**: any permission the app requests, what it is used for, and that the data is processed on the device only. 5. **Contacting you**: if a user emails you, you receive their email address and message and use them only to reply. 6. **Store operators**: downloads and purchases are handled by the store under its own policy. 7. **Children**: whether the app is directed to children. 8. **Changes**: how you will update the policy if you add features that collect data, with an effective date. A sentence like “Photos you edit in the app are processed on your device and are never uploaded to us” is far more convincing than “we respect your privacy”. For a complete outline, compare against [what a privacy policy should include](https://legalpolicygenerator.com/resources/what-should-a-privacy-policy-include). ## What counts as collecting data? The answer depends on who is asking, and the difference matters. **Apple** defines “collect” as transmitting data off the device in a way that allows you or your third-party partners to access it for longer than necessary to service the transmitted request in real time. Data processed only on device is not collected. If an authentication token or IP address is sent with a server call and not retained, Apple says you do not need to disclose it in App Store Connect. **Google** says data accessed and processed only on the device does not need to be disclosed in Data safety. Data sent off the device and processed ephemerally, in memory and only for a real-time request, still has to be included in your form answers, though it may not be shown on your listing. **Privacy law** is broader. Under the GDPR, “processing” covers any operation on personal data, including simply receiving it. If your app calls your server, that server sees the user's IP address, which can be personal data even if you never store it. So an app can honestly show “Data Not Collected” on a store label while its privacy policy still explains a transient server request. Being precise here is what makes a no-data policy trustworthy. ## Hidden collection: SDKs, crash reporters, and web views Most “we collect nothing” claims fail because of a dependency, not the developer's own code. Check each of these before you write a word: - **Crash reporting**: crash logs and stack traces sent to a provider are a Data safety data type on Google Play and a diagnostics category on Apple. - **Analytics**: even anonymous-sounding event SDKs usually send device and usage data. - **Advertising SDKs**: ads almost always involve device identifiers and IP addresses. - **Remote config, feature flags, and A/B testing** tools that call home on launch. - **Web views** that load your own pages with analytics or fonts from third-party servers. Google says data collected through a web view you control counts; web views where users browse the open web do not. - **Push notifications**, which require a device token stored on a server. - **Sign-in, cloud sync, or backup features** you added later. Google states that data transmitted off device by libraries and SDKs in your app counts, whether it goes to you or to a third party. If you find any of these, your app collects data, and the policy and store forms need to say so. The [Firebase privacy disclosures](https://legalpolicygenerator.com/resources/firebase-privacy-disclosures) guide shows what common Google SDKs send. ## What the app store collects versus what you collect Users sometimes ask how an app can claim to collect nothing when they had to sign in to the store to download it. The answer is that the store operator processes some data under its own privacy policy, and that is not your collection. Apple says this directly in its App Privacy guidance: if you collect data about your app from Apple frameworks or services, indicate what you collect and how you use it, but **you are not responsible for disclosing data collected by Apple**. Apple also notes that if payments are entered through a payment service outside your app and you never have access to the payment information, you have not collected it. Google Play similarly handles store accounts, downloads, and billing. Your policy can say this in one or two sentences: downloads, purchases, and store reviews are handled by Apple or Google under their own privacy policies, and you receive only the information those platforms provide to developers. If you look at aggregate statistics in Play Console or App Store Connect, describe them as aggregated reports provided by the store. Be careful not to overreach the other way. If you validate purchase receipts on your own server or use an Apple service such as CloudKit to sync data, describe what you do with that data. ## Does Apple's Data Not Collected label replace a privacy policy? No. The App Store's “Data Not Collected” label is the result of your App Privacy answers, not a substitute for the policy. Apple requires a privacy policy link for all apps, and the App Privacy details page lists the Privacy Policy URL as required. The label also has stricter edges than many developers assume. Apple lets you skip disclosing a data type only if it meets **all** of the optional disclosure criteria: it is not used for tracking, not used for third-party advertising or your own advertising and marketing, collected only in infrequent cases that are not part of the app's primary functionality and are optional for the user, and provided by the user through a clearly labeled interface where they affirmatively choose to submit it each time. An optional in-app feedback form can qualify; a crash reporter that runs on every launch does not. Two more Apple notes are worth knowing. Data collected on an ongoing basis after an initial permission request must be disclosed. And if you collect precise location but immediately coarsen it before storing, you declare coarse location. The [Apple App Store privacy policy guide](https://legalpolicygenerator.com/resources/apple-app-store-privacy-policy) covers the rest of the App Privacy questions. ## Common mistakes that make a no-data policy untrue These are the errors that turn a reassuring policy into a misleading one: - **Forgetting a crash reporter or analytics SDK** that a template project or engine enabled by default. - **Hosting the policy on a page with analytics** while the policy claims you never use tracking technologies of any kind. The policy covers the app; say so, or describe the website separately. - **Ignoring support channels**: an in-app contact form or support email means you receive personal data. - **Adding a feature later** such as sign-in, cloud sync, ads, or an AI feature that sends text to an API, without updating the policy and store forms. - **Absolute promises** like “we will never collect any data”. You cannot bind future versions; describe the current app and how you will announce changes. - **Copying another app's no-data policy** that describes a different set of features. A quick review before every release prevents almost all of these. If you want a fuller explanation of the risks of reusing someone else's text, read [can I copy a privacy policy?](https://legalpolicygenerator.com/blog/can-i-copy-a-privacy-policy). ## Do privacy laws still apply if your app collects nothing? If your app genuinely processes no personal data, many obligations under laws such as the GDPR simply have nothing to attach to. But “genuinely” is doing a lot of work in that sentence. Personal data appears in places a no-data app still touches. A support email contains a name and address. A server request carries an IP address. A crash log can contain a device identifier. Each of these is processing in the legal sense, even if it is brief, and the GDPR's transparency rules expect you to explain it. In the United States, California's CalOPPA requires a conspicuously posted privacy policy from operators of commercial online services that collect personally identifiable information from California residents. If you collect nothing at all, its core trigger may not apply, but the stores still require your policy anyway. The practical approach is to write the policy as if a regulator and a curious user will both read it: describe the transient and exceptional processing honestly, and keep the main message simple. The [do I need a privacy policy?](https://legalpolicygenerator.com/resources/do-i-need-a-privacy-policy) guide summarizes which laws and platforms trigger the requirement. ## Why do app stores require a privacy policy when you collect nothing? It feels like paperwork for its own sake, but the rule is explicit. Google Play's User Data policy says **apps that do not access any personal and sensitive user data must still submit a privacy policy**. Its Data safety guidance adds that even developers whose apps collect no user data must complete the Data safety form and provide a privacy policy link; in that case, the form and policy can say that no user data is collected or shared. Apple's App Review Guidelines require every app to include a privacy policy link in App Store Connect and within the app. There is a good reason behind it. Users cannot inspect your code, so the policy is your public, accountable statement that nothing leaves their device. It also gives users a way to contact you and tells them what would change if you later add features. So the question is not whether you need one, but how to write one that is short, accurate, and does not accidentally promise more than you can keep. The [Google Play privacy policy guide](https://legalpolicygenerator.com/resources/google-play-privacy-policy) explains the Play Console side in more detail. ## How to generate a minimal policy without overstating it A generator is useful here precisely because it should not add things you do not do. In the [app privacy policy generator](https://legalpolicygenerator.com/app-privacy-policy-generator), choose the application use case and answer the questions honestly: no accounts, no analytics or advertising providers, no payments handled by you, and whatever contact method you offer. Legal Policy Generator selects clauses deterministically from a versioned library based on those answers, so a no-data app gets a short document rather than paragraphs about advertising partners it does not have. The questionnaire, full preview, and simple HTML and PDF download are free with no account, and **optional public hosting adds $0.99 once** if you need a public URL for Play Console or App Store Connect. Advanced regional modules cost $5 if you want region-specific sections. Before you publish, read the preview line by line against your build. If a sentence describes something your app does not do, change your answers rather than leaving it in. Then follow our guide on [how to get a privacy policy URL](https://legalpolicygenerator.com/blog/how-to-get-a-privacy-policy-url) to publish it and test the link. ## Common questions ### Can my privacy policy just say “we collect no data”? A single sentence rarely holds up. Add who you are, how to contact you, what stays on the device, which permissions are used and why, how support emails are handled, and how you will announce changes. Those details make the claim verifiable and meet the store requirements for contact and retention information. ### Does Firebase Crashlytics or another crash reporter count as data collection? Generally yes. Crash logs sent off the device to a provider are a declared data type in Google Play's Data safety form, and Apple treats crash data as diagnostics. If your app includes a crash reporter in release builds, your policy and store labels should mention it. ### Is an IP address collected if my app calls an API? For Apple's label, not if it is used only to service the request and not retained. For Google Play, ephemeral processing must still be included in your form answers. Under privacy laws such as the GDPR, receiving an IP address is processing personal data, so mention transient server requests in your policy. ### What happens if my no-data claim turns out to be wrong? Inaccurate store declarations can lead to review rejection, enforcement notices, or removal, and a misleading privacy policy can attract complaints or regulatory attention. If you discover an SDK sending data, update the policy, Google Play Data safety, and Apple App Privacy answers together as soon as possible. ## Official sources - [Google Play User Data policy](https://support.google.com/googleplay/android-developer/answer/10144311?hl=en) - [Google Play Data safety guidance](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en) - [Apple App Privacy details, optional disclosure criteria](https://developer.apple.com/app-store/app-privacy-details/) - [Apple App Review Guidelines, section 5.1.1](https://developer.apple.com/app-store/review/guidelines/#privacy) - [Official EU GDPR text](https://eur-lex.europa.eu/eli/reg/2016/679/oj) Generated wording reflects supplied facts. It is not legal advice or a guarantee of compliance or enforceability.