Your app privacy details are a declaration, and the part people get wrong is the code they did not write.

What counts as collecting data, and what does not

Apple's definition of collecting is narrower than people expect. It means transmitting data off the device so that you or your third-party partners can read it for longer than servicing the request takes. Google's Data safety form uses the same test: collect means transmitting data from your app off a user's device. Data processed only on the device and never sent anywhere does not have to be disclosed. An app that keeps its data on the phone has almost nothing to declare.

The word that does the damage is partners. Apple defines third-party partners as analytics tools, advertising networks, third-party SDKs and other external vendors whose code you have added. It holds you responsible for their practices as well as your own. Google says the same thing, and points you at its SDK Index to see what a provider has published about itself. A crash reporter you never open is still a crash data declaration.

Your answers surface on the App Store product page under three headings. Data Used to Track You, Data Linked to You, and Data Not Linked to You. Linked means collected in a way tied to the person's identity, through their account, their device, or details such as a phone number. To claim data is not linked, Apple requires protections before collection, such as stripping direct identifiers, and forbids re-linking it afterwards. Apple's list of purposes has six entries and ends in a catch-all called Other Purposes. Google's has seven and no catch-all.

Apple publishes one exception, and it is narrow by design. A data type is optional to disclose only when it meets all four criteria. It is not used for tracking. It is not used for third-party advertising, for your own advertising or marketing, or for other purposes. It is collected only in infrequent cases that sit outside your app's primary functionality and are optional for the user. And the user supplies it in your own interface, with their name shown beside it, choosing to send it each time. Meet three of the four and you declare it. Apple's own example is an optional feedback form. Google has no equivalent test; its carve-outs are on-device processing, end-to-end encrypted data, and ephemeral processing, which you enter on the form but which is not shown to users.

Apple, app privacy details on the App Store, read 3 October 2026

Filling in App Privacy in App Store Connect

App Store Connect Help, read on 3 October 2026, gives the path. Open Apps, select your app, click App Privacy in the sidebar, then click Get Started on the right. A dialog asks whether you or your third-party partners collect data from the app. Say no and you save once, and you are finished. Say yes and you select every data type you collect, then open each one and answer the questions inside it. The answers are given at the app level. They have to cover every platform the app ships on, answered in the most inclusive way when one platform collects more than another.

When the data types are done, scroll to Product Page Preview to see what customers will read, then click Publish at the top right. A dialog makes you confirm that your answers are accurate and comply with the App Review Guidelines and applicable law. You also agree to update them if your practices change. Answering the questions needs the Account Holder, an Admin or an App Manager. A Marketing user can enter the privacy policy URL but not the answers.

Two timing details save a resubmission. Apple says you may update your answers at any time, and that you do not need to submit an app update to change them. A wrong data type is one Publish away from fixed. The privacy policy URL works the other way round. It is required for every app, a user privacy choices URL is optional, and changes to either release with your next app version. Fix a wrong policy URL before you submit, not after.

The tracking question has consequences past the label. Apple defines tracking as linking data from your app with third-party data for targeted advertising or advertising measurement. Sharing it with a data broker counts too. A yes puts Data Used to Track You on your product page, and it has to agree with your app tracking transparency prompt. Data linked only on the device and never sent off it is not tracking. Neither is sharing with a data broker purely for fraud prevention or security.

Google Play asks a different set of questions

Google's version is the Data safety form, and it lives on the App content page in Play Console, where you select Start under Data safety. The sharpest difference is sharing. Apple has no sharing question; it asks whether data is linked to the user and whether it is used to track them. Google asks, for every data type, whether it is collected, shared, or both. A handoff to another app on the same device counts as sharing, even though nothing left the phone. Transfers to a service provider acting on your instructions do not count. An SDK building advertising profiles across its other customers does.

Google also asks two questions Apple does not. Is all of the user data your app collects encrypted in transit? You can only answer yes if that holds for every SDK and library in the app. And do you give users a way to request deletion of their data? There is no prescribed mechanism. Google names in-app features, contact forms and a dedicated email alias as examples. You can also claim the badge if you automatically start deleting or anonymising collected data within 90 days of collection. Each data type is also marked required or optional, and optional only counts if every user, on any device and in any region, can opt in or opt out.

One exemption is worth knowing before you panic. Every app published on Google Play must complete the form, including apps on closed, open and production testing tracks. Apps that collect nothing still complete it and link a privacy policy. Apps active only on an internal testing track are exempt. Apple publishes no matching carve-out for TestFlight, so do not assume one exists. For the question-by-question pass, the google play data safety form walkthrough takes them in order.

Three optional badges hang off the same form, and none appear on their own. A commitment to follow the Play Families policy, opted into from the Security practices section. An Independent Security Review, run by a Google Authorized Lab against the OWASP mobile application security verification standard and paid for by you. And a badge for Unified Payments Interface support, shown only to users in India. Google is also explicit that Data safety and the permissions list on your listing are different things. The permissions list is generated from what your manifest declares. Data safety is what you told them.

Google Play Console Help, provide information for the Data safety section, read 3 October 2026

The answers that get people in trouble

Third-party code is the first one, and on iOS it is now enforced mechanically. A privacy manifest is a property list file named PrivacyInfo.xcprivacy, bundled inside an app or an SDK. It records the data types that code collects, and the required reason APIs it uses: a set of APIs Apple has designated as needing a declared reason to access. App Store Connect rejects uploads that contain an invalid privacy manifest, and emails you the path of the offending file. A set of commonly used third-party SDKs must ship a valid one before you can submit at all. Xcode combines every manifest in the project into one report when you prepare to distribute, which is the fastest honest way to learn what your dependencies collect.

Then the ones that catch people out. A webview showing your own content counts, because data collected through it must be declared on both stores. A webview in which the person is browsing the open web does not. IP addresses have no data type of their own. Both stores tell you to declare them by what you use them for, so an IP address used to work out a city is a location answer. Apple adds that if you collect precise location and coarsen it before storing, you declare Coarse Location. Google says an approximate location inferred from an IP address goes under Approximate location.

The last mistake is treating the form as a launch task. Both stores make accuracy a continuing obligation. Google says apps that misrepresent their data can have updates blocked or be removed from Google Play. Answers go stale the day somebody adds an SDK, so this belongs in the release checklist and not the launch checklist. Before you answer anything, spend an hour on what you are actually collecting. Both forms are only as good as your own picture of where your data goes.