Do I really need a privacy policy URL?

Yes. Both Apple's App Privacy and Google's Data safety form require a publicly accessible privacy policy URL.

If I don't run ads, is there nothing to declare?

Not quite. Analytics/crash SDKs, sign-in, and account features already produce collected data like identifiers and diagnostics. Declare based on actual behavior.

Can I fix the declaration later?

Yes. Apple lets you edit without resubmitting the app, and Google lets you edit in App content. Update it promptly whenever the app's behavior changes.

What happens if I declare it wrong?

A mismatch with actual behavior can lead to rejection, blocked updates, or even removal from the store. Both under- and over-declaring are risky.

App Data Safety & Privacy Form Guide — App Store & Google Play (2026)

By Nomadic Jeikei · Updated August 5, 2026

Both stores require you to self-declare what data your app handles before you ship, and both require a privacy policy URL. Your declaration must match the app's actual behavior — mismatches lead to rejection, blocked updates, or removal. Here's how Apple's and Google's forms are structured, how they differ, and the spots indie devs get wrong most. (Verified 2026-08 — the category lists change often, so confirm in the live console.)

Shared — self-declared, plus a privacy policy URL

Both the App Store and Google Play give you a form where you declare the data your app collects and shares. Both are (1) self-declared, (2) must match your app's actual behavior and your privacy policy, and (3) require a publicly accessible privacy policy URL.

The key principle: the data 'your app' handles includes data collected by the third-party SDKs you embed (ads, analytics, crash reporting). Even if you didn't write that code, declaring it is your responsibility.

Apple — App Privacy (nutrition labels)

Apple sorts your declared data into three tiers shown on the product page.

Data Used to Track You — data linked with third-party data for targeted advertising or ad measurement, or shared with a data broker.
Data Linked to You — data collected tied to the user's identity (account, device, etc.). Apple assumes 'linked' unless you de-identify before collection.
Data Not Linked to You — only qualifies if you strip identifiers before collection and re-linking is impossible.

The data-type categories include Contact Info, Health & Fitness, Financial Info, Location (precise/coarse), User Content, Search & Browsing History, Identifiers (User ID, Device ID), Purchases, Usage Data (Product Interaction, Advertising Data), and Diagnostics (Crash, Performance). You fill it in under App Store Connect → App Privacy, and can update it without an app release.

App Tracking Transparency (ATT): if you declare 'Data Used to Track You', you must get permission via the ATT framework before tracking. Without it, the advertising identifier (IDFA) returns all zeros and you can't track. The label (declaration) and ATT (runtime consent) must be consistent.

Google — Data safety

Collect vs share: transmitted off-device = 'collect'; handed to a third party = 'share'. End-to-end encrypted or on-device-only processing is exempt.
Purposes (8): App functionality, Analytics, Developer communications, Advertising/marketing, Fraud prevention/security/compliance, Personalization, Account management, Other.
You also declare whether data is encrypted in transit, whether users can request deletion, and whether collection is optional or required.

The data categories include Location, Personal info (name, email, user IDs, etc.), Financial info, Health & fitness, Messages, Photos & videos, Audio, Files & docs, Calendar, Contacts, App activity, Web browsing, App info & performance (crash logs, diagnostics), and Device or other IDs. You fill it in under Play Console → App content → Data safety.

When Google finds a discrepancy between your app's behavior and your declaration, it can require corrective action and take enforcement — rejection, blocked updates, or removal. A privacy policy is also required.

Key differences between the two

Aspect	Apple App Privacy	Google Data safety
Classifies by	Identity linkage (track/linked/not)	Collect vs share + purpose
Runtime consent	ATT prompt (required to track)	No OS-level prompt of its own
Unique fields	-	Encryption in transit, deletion request
Editing	Without an app resubmission	In App content, cross-checked vs behavior
Policy URL	Required	Required

Where indie devs go wrong

Forgetting third-party SDKs: data quietly collected by AdMob, Firebase/Analytics, Crashlytics, etc. — the most common source of mismatch.
'Ads = no data' myth: adding an ad network usually means declaring an advertising identifier / device ID, and on Apple it's classified as tracking, requiring ATT.
Under-declaring (an SDK collects silently) → triggers Google enforcement. Over-declaring 'to be safe' → a scarier label than reality, still flaggable as inaccurate.
Label ↔ ATT mismatch: declaring tracking but never showing the ATT prompt, or vice versa.
Forgetting crash/diagnostics: Crashlytics/diagnostics count as collected data (Apple Diagnostics / Google App info & performance).
Policy mismatch: the form and the privacy policy list different data types.

Frequently asked questions

Do I really need a privacy policy URL?: Yes. Both Apple's App Privacy and Google's Data safety form require a publicly accessible privacy policy URL.
If I don't run ads, is there nothing to declare?: Not quite. Analytics/crash SDKs, sign-in, and account features already produce collected data like identifiers and diagnostics. Declare based on actual behavior.
Can I fix the declaration later?: Yes. Apple lets you edit without resubmitting the app, and Google lets you edit in App content. Update it promptly whenever the app's behavior changes.
What happens if I declare it wrong?: A mismatch with actual behavior can lead to rejection, blocked updates, or even removal from the store. Both under- and over-declaring are risky.