Mobile App Privacy Labels: Write Accurate Store Disclosures and Close the Privacy Gap

Mobile app privacy labels are public statements about what an app collects and shares, yet they are often filled in once by someone who has never seen the app's network traffic, so they drift from what the app and its SDKs actually do. Apple's App Store privacy details and Google Play's Data safety section are required for almost every published app, and neither store verifies the answers before they go live. A label that understates collection is a transparency failure under privacy law and a store policy breach; a label nobody compares with the app's permissions is a missed warning for the security team approving apps. This guide explains what each store requires, how the key definitions work, how to build labels from evidence and keep them accurate release by release, and how enterprises can use labels when vetting third-party apps. It is written for mobile engineers, privacy and product owners, and security teams that review apps. Platforms are listed alphabetically.

Key takeaways

• Both stores make it mandatory and your responsibility. Apple requires privacy details to submit new apps and updates; Google requires the Data safety form for every app published on Play, including apps that collect nothing, and says it does not verify accuracy.
• SDKs count as your app. Data collected by analytics, advertising and other third-party SDKs must be declared by the app developer, whoever receives it.
• Definitions decide the answers. "Collect", "share", "linked to you" and "tracking" have precise store definitions; most label errors come from reading them loosely.
• Labels must be built from evidence. Generate them from a data inventory, Apple privacy manifests and observed network traffic, and re-check them every release.
• Labels are a security signal too. A gap between declared collection and requested permissions or observed traffic is a reason to reject or investigate an app.

What each store requires

The two schemes ask similar questions in different shapes. Apple's label is organised around data types, purposes and whether data is linked to the user or used for tracking. Google's Data safety section asks about collection and sharing per data type, plus security practices.

Data categories: Apple's categories include Contact Info, Health and Fitness, Financial Info, Location (precise and coarse), Sensitive Info, Contacts, User Content, Browsing History, Search History, Identifiers, Purchases, Usage Data, Diagnostics, Surroundings, Body and Other Data. Google's include Location, Personal info, Financial info, Health and fitness, Messages, Photos and videos, Audio files, Files and docs, Calendar, Contacts, App activity, Web browsing, App info and performance, and Device or other IDs. Apple defines precise location as resolution equal to or better than a latitude and longitude with three or more decimal places.

The definitions that decide your answers

• Collect (Apple): transmitting data off the device in a way that lets you or your third-party partners access it for longer than needed to service the request in real time. Data processed only on the device is not collected; an authentication token or IP address sent and not retained need not be disclosed. Data collected only for app functionality must still be declared.
• Collect (Google): transmitting data from the app off the user's device, including data sent by SDKs and pseudonymous data that can be re-associated with a user. Data processed ephemerally, held only in memory for no longer than the real-time request, must still be answered in the form but is not shown on the listing. End-to-end encrypted data that no intermediary, including the developer, can read is out of scope.
• Share (Google): transferring user data collected from the app to a third party, which includes on-device transfers to other apps. Transfers to service providers that process data on your instructions, certain legal transfers, anonymised data and user-initiated transfers are exempt from the sharing disclosure.
• Linked to the user (Apple): data is treated as linked unless de-identified before collection (for example by stripping user IDs or names) and you also do not try to re-link it or combine it with datasets that would. Personal data as defined in privacy law counts as linked.
• Tracking (Apple): linking data about a user or device collected from your app with third-party data for targeted advertising or advertising measurement, or sharing it with a data broker. Using an SDK that combines your app's data with other apps' data for ad targeting or measurement counts, even if you do not use it for that. Linking solely on the device, sharing with a data broker solely for fraud prevention or security, and credit reporting uses are not tracking.

Optional disclosure is narrow. Apple allows a data type to be left out only if it meets every criterion in one of four sets: general optional disclosure (not used for tracking or advertising, collected infrequently outside primary functionality, optional, and provided by the user each time with their name shown alongside), product improvement programmes (seven criteria including explicit opt-in and no link to identity), regulated financial services, and health research under ethics board approved consent. Apple adds that data collected on an ongoing basis after an initial permission request must be disclosed.

Apple privacy manifests and App Tracking Transparency

Apple's privacy manifest is a property list named PrivacyInfo.xcprivacy that apps and third-party SDKs bundle to record the data types they collect and the "required reason" APIs they use. It has four top-level keys:

Apple announced in February 2024 that from 1 May 2024 apps using listed APIs must include approved reasons in the manifest to upload new apps or updates, and that SDKs on its list of commonly used third-party SDKs need a privacy manifest, plus a signature when added as a binary dependency. Other SDKs should include a manifest if they use a required reason API, collect data about users, enable the app to collect data, or contact tracking domains. When you archive an app, Xcode combines the manifests into one privacy report that helps prepare the label.

App Tracking Transparency: on iOS, iPadOS and tvOS 14.5 or later, apps need the user's permission through the ATT framework to track them or access the advertising identifier, which otherwise returns all zeros. Apple's guidance states that you may not use another identifier, such as a hashed email address, to track a user who has not granted permission, that tracking inside a webview needs ATT too, that functionality may not be gated on consent (App Review Guideline 5.1.2(i)), and that fingerprinting a device is prohibited. Your label, your manifest's tracking flag and your ATT behaviour must tell the same story.

Building labels from evidence

An accurate label is the output of a data inventory, not a form filled from memory. The ordered approach below works for a single app or a portfolio.

1. Inventory first-party data flows: for each screen and backend call, list the data types sent off the device, where they go, how long they are kept and why. Reuse your record of processing; see the Data Mapping and ROPA Guide.
2. Inventory SDKs: list every SDK and library with its version, the data it collects, its own privacy manifest (Apple) or published Data safety guidance (Google), and whether it shares data with its vendor for that vendor's purposes.
3. Observe actual traffic: run the release build on test devices through an intercepting proxy, exercise the main journeys with and without consent, and record every destination domain and the data types sent. Compare with the inventory. OWASP MASVS-PRIVACY notes that spotting data not mentioned in the store listing or privacy policy needs careful manual checking.
4. Apply the definitions: for each data type decide collected or not, shared or not (Google), linked or not and tracking or not (Apple), and purposes. Record the reasoning, especially for any optional disclosure or exemption claimed.
5. Generate artefacts: update the app's privacy manifest, review the Xcode privacy report, and draft both store forms from the same inventory so they cannot contradict each other.
6. Review and approve: privacy, legal and engineering sign off. Check the label against the privacy policy and in-app consent text.
7. Publish and diarise: submit with the release, then re-run the comparison on every release that adds an SDK, a data type, a destination or a new purpose. Apple answers can be corrected at any time; Google requires corrections when practices change.

Small and large teams: a small team with one app can keep the inventory as a spreadsheet beside the release checklist and repeat the traffic check each release. A large organisation should make the label part of the release pipeline: block a build that adds an SDK or tracking domain without an inventory update, and assign one accountable owner per app.

Account deletion and data rights on the label

Both stores connect labels to user rights. Google requires apps that let users create an account to offer account deletion from inside the app and through a web link that works without reinstalling the app, and to answer the Data deletion questions in the Data safety form; the deadline was 7 December 2023, with an extension to 31 May 2024, after which non-compliant apps can be removed. Deleting an account must delete associated user data, and data kept for security, fraud prevention or regulatory reasons must be disclosed. Apple asks for a public privacy policy URL and offers an optional privacy choices URL explaining how users access or delete data.

Treat these as engineering features with tests, not text on a form: the deletion flow should actually remove data across your systems and ask service providers to do the same. See the Data Minimisation guide.

Using labels to vet third-party apps

Security teams approving apps for managed devices can treat the store label as a declared baseline and look for contradictions. The Mobile App Permissions guide covers the permission side in depth; the label adds what the developer claims about data leaving the device.

Limits: labels are self-declared, and Google states plainly that it does not verify them. Use them to prioritise testing, never as proof. For apps processing sensitive corporate data, run the same traffic comparison you would run on your own app; the Mobile App Security Testing Guide describes the tooling.

Where identity fits

Identifiers sit at the centre of label decisions. User IDs, device IDs, the advertising identifier and the identifier for vendor all decide whether data is "linked" and whether it enables tracking; Apple's guidance says the IDFV may be used for analytics across apps from the same provider but may not be combined with other data to track users across other companies' apps and websites. On the security side, SDK keys and analytics tokens embedded in apps are machine credentials: if extracted they can be used to send or read data in your analytics or crash reporting tenant. Keep their scope minimal and review them like any other API key. See the OWASP Mobile Top 10 M1 Improper Credential Usage Guide.

Detection and measurement

• Label drift rate: releases where observed traffic or the SDK list differed from the published label before correction.
• SDK coverage: percentage of SDKs with a current privacy manifest or documented data practices.
• Time to correct: days from detecting a mismatch to an updated label.
• Tracking domain hygiene: tracking domains contacted that are not listed in NSPrivacyTrackingDomains (should be zero).
• Deletion flow success: test deletion requests completed end to end within the stated time.
• Vetting findings: third-party apps rejected or restricted because of label and behaviour contradictions.

Framework mapping

Common failure patterns

• Forgetting SDK collection: the label covers first-party data only, while analytics, crash reporting and advertising SDKs send identifiers and usage data. Both stores make the developer responsible for that data.
• "Not linked" without real de-identification: data is sent with a user or device ID and declared not linked. Apple treats it as linked unless de-identified before collection and never re-linked.
• Labels that never change: written at launch and not touched as SDKs and features were added. Drift is the normal state without a release check.
• Tracking declared "no" with ad SDKs present: an SDK that combines data across apps for ad targeting or measurement is tracking under Apple's definition, even if you do not use that feature.
• Treating "no data collected" as a security clearance: enterprise reviewers approve an app on its label alone, though neither store verifies labels before publication.
• Deletion that only deletes the login: the account is removed but analytics, backups and provider copies keep the data the label says can be deleted.

Practitioner checklist

• Keep a data inventory per app covering first-party flows and every SDK, with purposes and retention.
• Read the current Apple and Google definitions of collect, share, linked and tracking before each label review.
• Ship a complete PrivacyInfo.xcprivacy, use SDK versions that include manifests, and review the Xcode privacy report.
• Compare observed release traffic with the inventory and label on every release that changes SDKs, data types or destinations.
• Draft both store forms from the same inventory and check them against the privacy policy and consent text.
• Make ATT behaviour, the manifest tracking flag and the label agree.
• Implement and test in-app and web account deletion that removes associated data.
• For enterprise app approval, flag gaps between labels, permissions and observed traffic, and never treat a label as proof.

Standards and references

• Apple: App Privacy Details on the App Store
• Google: Provide Information for Google Play's Data Safety Section
• Apple: Privacy Manifest Files
• Apple: User Privacy and Data Use
• Google: Understanding Google Play's App Account Deletion Requirements
• Apple: Privacy Updates for App Store Submissions
• OWASP: Mobile Application Security Verification Standard

Related NHI Mgmt Group resources: OWASP Mobile Top 10 M6 Inadequate Privacy Controls Guide · Mobile App Permissions · iOS App Security Guide · Android App Security Guide · Privacy by Design Guide for Engineering Teams