app store
Apple Privacy Labels vs Google Play Data Safety, Side by Side
How Apple's App Privacy label and Google Play's Data safety form map, what tracking, linked and shared mean, and what common SDKs make you declare.
By Kyle Hurst ·
Ship an app on both stores and you fill in the same privacy questionnaire twice: Apple’s App Privacy details (the “privacy nutrition label”) and Google Play’s Data safety form. They look similar, but they’re not interchangeable. Apple wants to know whether each data type is linked to the user and whether it’s used for tracking. Google wants to know whether it’s collected and whether it’s shared. And both hold you responsible for everything your SDKs send, whether or not you wrote that code. That last part trips up most indie developers.
This post puts the two forms side by side, maps the data types, explains the definitions that actually change your answers, and works through a typical indie stack. Everything here comes from Apple’s and Google’s own documentation and the SDK vendors’ disclosure pages as of October 2026.
If you’d rather start from a draft, our App Privacy Policy Generator takes the data and SDKs you pick and produces a privacy policy plus a store-declarations cheat sheet for both forms. Treat it as a starting point you verify, not a final answer.
What each form is and where it shows up
| Apple App Privacy | Google Play Data safety | |
|---|---|---|
| Where you fill it in | App Store Connect, App Privacy section | Play Console, App content › Data safety |
| Where users see it | Your App Store product page | The Data safety section of your store listing |
| Who must complete it | Required to submit new apps and app updates | Every app on a closed, open or production track. Apps only on internal testing are exempt |
| If you collect nothing | You still answer the questionnaire | You still complete the form and provide a privacy policy link |
| Changing answers | Any time, no new build needed | Edit in Play Console |
| Core questions per data type | Linked to the user? Used for tracking? Purposes? | Collected? Shared? Required or optional? Purposes? |
| Extra sections | None beyond data types | Security practices (encryption in transit, deletion requests), account deletion URL |
Two things from that table catch people. First, Google requires Data safety for closed testing too, so if you’re a new personal account running the mandatory closed test before production access, you need the form done before testers can install. Second, Apple lets you update your answers without shipping a build, so there’s no excuse to leave a stale label up after you remove an SDK.
On the live App Store, declared types are grouped under headings like “Data Used to Track You”, “Data Linked to You” and “Data Not Linked to You”. Apple’s documentation describes the same split in terms of tracking and linkage; App Store Connect shows a product page preview before you publish.
How the data types line up
Apple uses 16 top-level categories and Google uses 14, and they’re cut differently. Here’s the mapping for the types most apps actually touch:
| What you collect | Apple type | Google Play type |
|---|---|---|
| Name | Contact Info › Name | Personal info › Name |
| Contact Info › Email Address | Personal info › Email address | |
| Phone number | Contact Info › Phone Number | Personal info › Phone number |
| Postal address | Contact Info › Physical Address | Personal info › Address |
| Account / user ID | Identifiers › User ID | Personal info › User IDs |
| Advertising ID, installation ID | Identifiers › Device ID | Device or other IDs |
| Precise location | Location › Precise Location | Location › Precise location |
| Approximate location | Location › Coarse Location | Location › Approximate location |
| Card details you handle | Financial Info › Payment Info | Financial info › User payment info |
| Purchases | Purchases › Purchase History | Financial info › Purchase history |
| Health / fitness | Health & Fitness › Health / Fitness | Health and fitness › Health info / Fitness info |
| Contacts | Contacts › Contacts | Contacts › Contacts |
| Photos, videos | User Content › Photos or Videos | Photos and videos › Photos / Videos |
| Voice recordings | User Content › Audio Data | Audio files › Voice or sound recordings |
| Messages | User Content › Emails or Text Messages | Messages › Emails / SMS or MMS / Other in-app messages |
| Files | User Content › Other User Content | Files and docs |
| Calendar events | No dedicated type (Other Data) | Calendar › Calendar events |
| Taps, screens, events | Usage Data › Product Interaction | App activity › App interactions |
| In-app search | Search History | App activity › In-app search history |
| Installed apps | No dedicated type (Other Data) | App activity › Installed apps |
| Ads seen | Usage Data › Advertising Data | No dedicated type (covered by Advertising purpose) |
| Browsing outside the app | Browsing History | Web browsing › Web browsing history |
| Crash logs | Diagnostics › Crash Data | App info and performance › Crash logs |
| Performance metrics | Diagnostics › Performance Data / Other Diagnostic Data | App info and performance › Diagnostics / Other app performance data |
| Race, religion, orientation, etc. | Sensitive Info | Personal info › Race and ethnicity / Political or religious beliefs / Sexual orientation |
The notable mismatches: Apple puts User ID under Identifiers while Google files it under Personal info. Apple has a Purchases category of its own while Google folds purchase history into Financial info. And neither form has a dedicated “IP address” type, so you declare what the IP is used for (usually approximate location) rather than the address itself.
The two location thresholds differ in wording too. Google calls location “precise” when it’s within an area smaller than 3 square kilometers. Apple calls it precise when it has three or more decimal places of latitude and longitude.
Purposes don’t map one-to-one either. Apple offers Third-Party Advertising, Developer’s Advertising or Marketing, Analytics, Product Personalization, App Functionality and Other Purposes. Google offers App functionality, Analytics, Developer communications, Advertising or marketing, Fraud prevention/security/compliance, Personalization and Account management.
The definitions that change your answers
”Collect” means the same thing, mostly
Both stores define collection as data leaving the device. Apple: “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: transmitting data off a user’s device, including data sent by libraries and SDKs.
Data that’s processed only on the device isn’t collected on either store. Google also spells out two more exemptions: ephemeral processing (held only in memory, no longer than needed for a real-time request) and data that’s end-to-end encrypted so that nobody but the sender and recipient can read it. Apple’s real-time wording covers similar ground to Google’s ephemeral rule.
Apple’s “tracking” is narrower than you think, and broader
Apple defines tracking as “linking data collected from your app about a particular end-user or device, such as a user ID, device ID, or profile, with Third-Party Data for targeted advertising or advertising measurement purposes, or sharing data collected from your app about a particular end-user or device with a data broker.”
So product analytics on your own data isn’t tracking, and using the IDFV for analytics across your own apps doesn’t need an App Tracking Transparency prompt. But Apple also says that placing a third-party SDK in your app that combines your users’ data with other developers’ apps for ad targeting or measurement is tracking, “even if you don’t use the SDK for these purposes.” If any type is marked as used for tracking, you need the ATT prompt before tracking happens.
Apple’s “linked” is the default
Apple treats data as linked to the user’s identity unless it’s de-identified or anonymized before collection. If you tie analytics events to a signed-in account, they’re linked. “We don’t look at it” doesn’t make it unlinked.
Google’s “shared” excludes service providers
Google defines sharing as transferring user data to a third party. Transfers to a service provider that processes the data on your behalf and under your instructions don’t count, and neither do legally required disclosures, transfers the user starts themselves, or anonymized data. That’s why an analytics or crash-reporting vendor acting as a processor is usually “collected, not shared”, while an ad network that uses the data for its own purposes is “shared”.
Google also asks whether each type is required or optional. If your app’s primary functionality needs it, it’s required. You can only call it optional if every user can opt out or choose not to provide it.
Apple’s optional-disclosure rule is strict
Apple lets you skip disclosing a data type 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.
- It’s collected only in infrequent cases that aren’t part of the app’s primary functionality, and it’s optional for the user.
- The user enters it in your app’s interface, it’s clear what’s being collected, their name or account name is shown prominently on the form, and they choose to submit it each time.
Think of a one-off “report a problem” form. Meeting three of the four isn’t enough. Apple has separate carve-outs for opt-in product improvement programs, regulated financial services and approved health research, each with its own conditions.
The SDK trap
Both stores are explicit that SDKs are your problem. Apple says you must cover “the practices of third-party partners whose code you integrate into your app.” Google says you “must reflect data collection or sharing carried out by such third-party code in the Data safety form” and that you’re “solely responsible” for accuracy. Google also notes its review isn’t designed to verify your answers, so approval doesn’t mean your form is right. If Google later finds you’ve misrepresented your data, it can require a fix, block updates or remove the app.
Here’s what common SDKs collect in their default configuration, per each vendor’s disclosure docs:
| SDK | Collects by default | Notes |
|---|---|---|
| Firebase / Google Analytics | App instance ID, Android advertising ID (on by default), IDFV on iOS, IP-derived coarse location, screen views and events, auto-logged in-app purchase events | IDFA only if you link AdSupport. google_analytics_adid_collection_enabled=false stops ad ID collection on Android |
| Firebase Crashlytics | Stack traces, device and OS metadata, a Crashlytics installation UUID, Firebase installation ID | No advertising ID or IP listed. Custom keys, logs and user IDs only if you set them |
| Google AdMob | IP, advertising ID (ATT-gated on iOS), App Set ID on Android, interactions, ads seen, diagnostics | Google is an independent controller, so it’s collected and shared. Tracking on iOS when ads are personalized |
| Meta (Facebook) SDK | Automatic App Install, App Launch and Purchase events, advertising ID, device attributes, IP | Auto-logging is on until you set FacebookAutoLogAppEventsEnabled to false. Expect “Used to Track You” and “shared” |
| RevenueCat | Purchase history (required, can’t be turned off), anonymous app user ID, device type, OS, locale | Device identifiers and IP only if you opt in. Acts as a processor |
| Mixpanel | Random distinct ID, events, IP-derived coarse location, device properties | Vendor says it doesn’t track in Apple’s sense |
One caution on Apple’s privacy manifests. Xcode’s privacy report aggregates the PrivacyInfo.xcprivacy files your SDKs ship, and it’s a good cross-check. It isn’t a complete answer, though. When we checked on October 21, 2026, Mixpanel’s shipped iOS manifest declared no collected data types, even though Mixpanel’s own documentation lists the defaults above. A report built from manifests can under-report, so read the vendor’s disclosure page too.
Your privacy policy has to agree
Both stores require a privacy policy link, even for apps that collect nothing (what a no-data policy should say). Apple’s guideline 5.1.1(i) says the policy must identify what data the app collects, how, and all its uses, and confirm that third parties such as analytics tools, ad networks and SDKs give the same protection. Google’s User Data policy says the policy must comprehensively disclose what your app collects and shares, and that the Data safety section, where relevant, “must be consistent with the disclosures made in the app’s privacy policy.”
In practice, a privacy policy that leaves out something your form declares, or something an SDK obviously collects, is one of the more common reasons for a rejection or a “fix this” notice. Keep three things in sync: the store forms, the policy and the SDKs actually in your build.
Worked example: an indie subscription app
Say you ship a habit tracker on iOS and Android with Firebase Analytics, Firebase Crashlytics, RevenueCat for subscriptions, and Sign in with Apple for accounts. On Android, assume the same account system through a web-based Sign in with Apple flow. No ads, no ad SDKs, and you haven’t enabled Google Signals or linked Google Ads.
Apple App Privacy
| Data type | Why | Purposes | Linked | Tracking |
|---|---|---|---|---|
| Contact Info › Email Address | Sign in with Apple returns an email (real or Hide My Email relay) | App Functionality | Yes | No |
| Contact Info › Name | Only if you store the name Apple returns on first sign-in | App Functionality | Yes | No |
| Identifiers › User ID | Your account ID, plus any custom RevenueCat or Firebase user ID | App Functionality, Analytics | Yes | No |
| Identifiers › Device ID | Firebase IDFV, Crashlytics installation UUID | Analytics, App Functionality | Yes, once tied to a signed-in user | No |
| Usage Data › Product Interaction | Firebase screen views and events | Analytics | Yes | No |
| Purchases › Purchase History | RevenueCat receipts, Firebase’s automatic purchase events | App Functionality, Analytics | Yes | No |
| Location › Coarse Location | Firebase derives it from IP | Analytics | Yes | No |
| Diagnostics › Crash Data | Crashlytics | App Functionality, Analytics | Your call (see below) | No |
| Diagnostics › Performance Data, Other Diagnostic Data | Crashlytics, Firebase | App Functionality, Analytics | Your call | No |
Nothing here is tracking, so no ATT prompt. That changes the moment you add an ad SDK, Meta’s SDK or link Firebase to Google Ads. You don’t declare Payment Info: card details go through Apple’s payment sheet and you never see them, which Apple says isn’t collection.
On “linked”: if you call setUserID in Crashlytics or Analytics, crash and usage data is linked. If you never attach an identity, you can argue some diagnostics aren’t linked, but remember Apple’s default is linked unless de-identified before collection. When in doubt, “Yes” is the safer answer.
Google Play Data safety
| Data type | Collected | Shared | Purposes | Required? |
|---|---|---|---|---|
| Personal info › Email address | Yes | No | App functionality, Account management | Required for accounts |
| Personal info › Name | If stored | No | Account management | Depends |
| Personal info › User IDs | Yes | No | App functionality, Analytics, Account management | Required |
| Device or other IDs | Yes | No | Analytics, App functionality | Required unless users can opt out |
| App activity › App interactions | Yes | No | Analytics | Same |
| Financial info › Purchase history | Yes | No | App functionality, Analytics | Required |
| Location › Approximate location | Yes | No | Analytics | Same |
| App info and performance › Crash logs | Yes | No | App functionality, Analytics | Same |
| App info and performance › Diagnostics | Yes | No | App functionality, Analytics | Same |
“Shared: No” rests on Firebase and RevenueCat acting as service providers. RevenueCat says outright that it’s a processor. Firebase Analytics is a processor by default, but turning on Google Signals or Ads linking expands Google’s own use of the data, and at that point you should revisit “shared”. Remember that Firebase collects the Android advertising ID by default; if you don’t need it, turn it off and keep the Device or other IDs entry for the installation IDs.
Then answer the security section: data is encrypted in transit (yes, if everything goes over HTTPS), and users can request deletion. Because the app creates accounts, Google also wants an in-app deletion path and a web URL where users can request deletion without reinstalling the app (our account deletion guide covers both stores’ rules). Apple separately requires in-app account deletion, and with Sign in with Apple you need to revoke the user’s tokens through Apple’s REST API when they delete.
Before you submit
- List every SDK in your build, including transitive ones, and read each vendor’s disclosure page.
- Fill both forms from that list, using the mapping table above.
- Make sure your privacy policy names the same data, purposes and third parties.
- Cross-check with Xcode’s privacy report, knowing it can miss things.
- Re-check both forms whenever you add or remove an SDK.
Our App Privacy Policy Generator does steps 2 and 3 in one pass and gives you a cheat sheet of what to tick on each form. For the rest of the release, the App Store submission checklist and Google Play publishing checklist cover where these forms fit among everything else the stores ask for. If you’re also preparing artwork, see our guide to App Store header and search image sizes.
This post is general information, not legal advice. SDK behavior described here reflects vendor documentation and default settings as of October 2026; your configuration may differ, so verify against current vendor docs and talk to a lawyer about your specific app.