What App Privacy Details Actually Are
App Privacy details are a questionnaire you complete in App Store Connect, under your app's App Privacy section. Your answers generate the privacy label that appears on your App Store product page - the section a user sees titled Data Used to Track You, Data Linked to You, and Data Not Linked to You. Apple requires it before you can submit for review, and it applies to every app regardless of size.
It is not a code change. You are describing behavior that already exists in your app. That is why it feels deceptively easy and why so many first submissions get it wrong: nothing in your project fails if you answer inaccurately, so there is no error message pointing at the problem.
App Privacy Details vs the Privacy Manifest
These get confused constantly, and they are two different things that serve two different purposes.
| App Privacy details | Privacy manifest | |
|---|---|---|
| Where it lives | App Store Connect, in a web form | A PrivacyInfo.xcprivacy file inside your app bundle or an SDK's bundle |
| What it is | Your declaration of what data is collected and how it is used | A machine-readable file declaring data collection plus reasons for using certain APIs |
| Who writes it | You, once per app, updated when behavior changes | You for your own code, and each third party SDK ships its own |
| When it blocks you | You cannot submit for review without completing it | Missing or invalid manifests from required SDKs cause upload or review failures |
The practical relationship: if a manifest in your bundle says an SDK collects device identifiers, and your App Privacy details say you collect nothing, those two statements contradict each other. Fix the questionnaire, not the manifest - the manifest is usually the honest one.
Do This First - Audit Your Dependencies
Do not open the questionnaire yet. Open your package file first. The questionnaire asks what your app collects, and your app collects whatever your SDKs collect. You are answering for all of it.
- List every third party dependency that touches the network, storage, the device, or the user. Analytics, crash reporting, ads, attribution, authentication, payments, push notifications, feature flags, chat and support widgets, and any backend SDK.
- For each one, open its documentation and find its privacy disclosure page. Most major SDKs now publish exactly which data types they collect and how each is used, specifically so you can fill in this form.
- Write the data types down in a scratch file grouped by SDK. You will be answering the same set of questions repeatedly, and having the list in front of you turns a confusing hour into a mechanical twenty minutes.
- Add your own app's collection on top - account signup fields, anything you write to your own backend, anything you store that identifies a user.
The Three Questions Apple Asks About Every Data Type
Once you select a data type in the questionnaire, Apple asks the same three things about it. Understanding these three up front is what makes the rest of the form fast.
- What is it used for? You pick from purposes like app functionality, analytics, product personalization, developer advertising, third party advertising, or other. One data type can have several purposes.
- Is it linked to the user's identity? If the data is associated with an account, a device identifier, or anything else that can tie it back to a specific person, it is linked. Truly anonymous aggregate data is not linked.
- Is it used for tracking? Tracking has a specific meaning here: linking your data with data from other companies' apps or websites for targeted advertising or measurement, or sharing it with a data broker. If you answer yes, your app needs to request tracking permission through App Tracking Transparency.
Where First Submissions Go Wrong
These are the failure patterns worth knowing before you start, because each one is easy to avoid and annoying to discover after the fact.
| Mistake | Why it happens | The fix |
|---|---|---|
| Declaring no data collected | You did not write any collection code, so it feels true | Check your SDKs. A crash reporter or analytics library almost always collects something, which means the answer is not none |
| Forgetting crash reporting | Crash data does not feel like user data | Crash logs are diagnostics, which is a declarable data type. Declare it, usually under app functionality |
| Missing the device identifier | Ad and attribution SDKs pull it without you calling anything | If any SDK can access an advertising identifier, that is Identifiers, and it usually raises the tracking question |
| Declaring optional features you did not ship | You planned a login and answered as if it exists | Answer for the build you are submitting, not the roadmap. Update the questionnaire when the feature ships |
| Never updating after adding an SDK | The form is completed once and forgotten | Adding a dependency is the trigger to reopen App Privacy. Put it in your release checklist |
The Privacy Policy URL Requirement
The App Privacy section also requires a privacy policy URL, and it must be a working link to a page that actually loads. This trips people up on a first launch because they are focused on the questionnaire and treat the URL as a formality.
Two things worth getting right. First, the page has to be publicly accessible without a login, and it has to still be there after review - a temporary page you take down is a problem. Second, the policy should describe the same collection you just declared in the questionnaire. A reviewer comparing the two and finding a contradiction is a slower conversation than writing the policy accurately in the first place.
A Twenty Minute Workflow
Putting it together, here is the order that keeps this from eating an afternoon.
- Build your dependency table before opening App Store Connect. This is the part that takes real time and it is the part that determines every answer.
- For each dependency, pull its published privacy disclosure and note the data types, the purposes, and whether it tracks.
- Merge everything into one list of data types, deduplicated, with the union of purposes for each.
- Open App Privacy in App Store Connect and work down your merged list. Because you prepared it, this step is now data entry rather than decision making.
- Answer the tracking question deliberately for each type, and if any answer is yes, confirm your app implements the tracking permission request.
- Write or update your privacy policy from the same list, publish it at a stable URL, and paste that URL in.
- Add a line to your release checklist: any new dependency means reopening App Privacy before the next submission.
Done in that order, this is a twenty minute task. Done by opening the questionnaire cold and guessing, it is an hour of confusion followed by a label that does not match your app.
Short, practical drops on app ideas, validating fast, store listings, and passing app review. No spam, unsubscribe anytime.
Frequently asked questions
Do I have to fill out App Privacy details for every app?
Yes. Apple requires the App Privacy questionnaire to be completed before you can submit any app for review, regardless of whether your app collects data. Even a fully offline app has to go through the questionnaire and declare that no data is collected.
What is the difference between App Privacy details and the privacy manifest?
App Privacy details are a questionnaire you complete in App Store Connect that generates your App Store privacy label. The privacy manifest is a PrivacyInfo.xcprivacy file inside your app bundle, and each third party SDK ships its own. One is a web form you fill in, the other is a file in your project, and the two need to describe the same behavior.
Can I say my app collects no data if I use analytics?
No. The questionnaire asks about data collected by your app including any third party SDKs you bundle. Analytics libraries, crash reporters, advertising SDKs, and authentication providers all collect data on your behalf, so shipping any of them means the honest answer is not none.
Does crash reporting count as data collection?
Yes. Crash logs and performance data fall under diagnostics, which is a declarable data type. In most cases the purpose is app functionality, and whether it is linked to the user depends on whether your crash reporter attaches a user or device identifier.
What counts as tracking in the App Privacy questionnaire?
Tracking means linking data collected in your app with data from other companies' apps or websites for targeted advertising or advertising measurement, or sharing user data with a data broker. If you answer yes to tracking, your app must request permission through App Tracking Transparency.
Do I need to update App Privacy details when I add a new SDK?
Yes. Your declaration has to reflect the build you are shipping. Adding an analytics, ads, auth, or crash reporting dependency is the moment to reopen App Privacy in App Store Connect and confirm your answers still hold. Adding this to your release checklist is the reliable way to catch it.
Last reviewed by David on August 16, 2026
