How to Prepare App Store Privacy Labels: A Step by Step Guide

Apple calls them "Privacy Nutrition Labels" in its official documentation. In practice, users see this summary on your product page before they download. As a result, the label is part of both App Review and user trust. In addition, you must provide this information to submit new apps and app updates, as Apple states on its App privacy details page.

In this guide, Talha Aslan and team share the order we follow in store projects. First, we clarify the concepts. Then we build a data inventory. After that, we move into App Store Connect. That way, you get an accurate disclosure from the start instead of a rushed form on launch day.

Who is responsible for App Store privacy labels?

The short answer: the developer account that publishes the app. Apple expects your answers to cover your own practices and those of the third-party partners whose code you add to the app. Third-party partners means analytics tools, ad networks, third-party SDKs (software development kits), and other external vendors. In other words, the data an analytics kit collects belongs in your disclosure too.

In App Store Connect, users with the Account Holder, Admin, or App Manager role can enter these answers. The Marketing role can also edit the privacy policy URL. If you work with an agency or a freelance developer, put in writing who enters the answers and who approves them.

On the other hand, Apple's own frameworks follow a separate rule. If you collect data about your app from Apple frameworks or services, you state what you collect and how you use it. However, you are not responsible for disclosing data that Apple itself collects. This distinction removes a lot of confusion in apps that rely on Sign in with Apple or Apple's payment infrastructure.

How do you build a data inventory before you start?

Above all, the quality of the label depends on the inventory work you do before the form. An inventory is a simple table that shows every piece of information the app sends off the device, where it goes, and why. We fill it out together with the developer, the product owner, and the marketing lead, because each of them knows a different data flow.

• Walk through every screen of the app and note each field a user fills in.
• List the API calls to your servers and the identifiers that travel with them.
• Export every dependency, meaning every library you added to the project.
• Ask the marketing team about ads, retargeting, and newsletter plans.
• Check in-app web views and the forms on those pages separately.

This work may take a few hours. Still, it speeds up every later step. Additionally, you reuse the same table for your privacy policy, your consent texts, and your Google Play disclosure. In short, one source keeps three documents consistent.

What exactly does Apple mean by "collect"?

According to Apple, collecting means transmitting data off the device in a way that lets you or your partners access it for longer than necessary to serve the request in real time. In other words, this definition draws the line for your disclosure list. Therefore, not every network request automatically needs a disclosure.

• Data you process only on the device does not count as collected and needs no disclosure.
• An authentication token or IP address that goes out with a server call but that you do not retain needs no disclosure.
• Web traffic data from a web view needs a disclosure, unless you simply let the user browse the open web.
• For IP addresses, you pick the relevant type based on how you use them, such as precise location, coarse location, device ID, or diagnostics.

For example, consider a sample scenario. Your weather screen reads the precise location, coarsens it immediately, and never stores the precise value. In that case, Apple advises you to disclose Coarse Location. These fine distinctions are what make a label accurate. So read the word "collect" through Apple's definition, not its everyday meaning.

Which data types do you need to select?

Specifically, Apple groups data types into categories, and each category contains narrower options. The list below summarizes the main headings on the official page:

• Contact Info: name, email address (including a hashed email address), phone number, physical address, and other contact info.
• Health and Fitness: health data, plus fitness and exercise data.
• Financial Info: payment info, credit info, and other financial info.
• Location: precise location and coarse location.
• Sensitive Info: special categories such as ethnic data, religious beliefs, or biometric data.
• Contacts: the phone's contact list or a social graph.
• User Content: messages, photos or videos, audio data, gameplay content, customer support records, and other content.
• Browsing History and Search History.
• Identifiers: User ID and Device ID.
• Purchases, Usage Data (product interaction, advertising data), and Diagnostics (crash and performance data).
• Surroundings and Body data, plus Other Data Types for anything without a match.

Payments, however, come with an important exception. If users enter payment info in an outside payment service and you never have access to it, Apple does not treat it as collected. Meanwhile, you mark generic free text fields as "Other User Content" and voice recordings as "Audio Data." However, if a form asks specifically for a name or email, you also select that data under its own type.

How do you tell linked data from data not linked to the user?

According to Apple, data often links to the user's identity. If you did not put de-identification or anonymization protections in place before collection, you mark the data as linked. Two conditions stand out for the "not linked" option.

First, you strip direct identifiers such as a user ID or name before collection. Second, you do not try to link the data back to the user later, and you do not combine it with other datasets that would reveal identity. Also, Apple considers anything that privacy laws call personal data to be linked to the user.

In practice, the most common mistake looks like this. The team thinks of analytics data as "anonymous," yet the same events reach the server with an account ID. In that case, the data is linked. That's why you should ask your developers one simple question before you answer: which identifier travels with this event? If the answer is an account ID or an email, choose linked.

Admittedly, unlinked data tends to worry users less on the product page. Even so, don't pick that option because it looks nicer. You fill out the label to describe reality, not to reassure people, and App Review looks at that consistency.

What does tracking mean, and how does it relate to ATT?

Under Apple's definition, tracking means linking user or device data from your app with Third-Party Data for targeted advertising or advertising measurement. Likewise, sharing that data with a data broker counts as tracking. Third-Party Data refers to data from apps, websites, or offline properties that you do not own.

• Showing targeted ads in your app based on data from other companies' apps and websites is tracking.
• Sharing an email list or advertising ID with an ad network for retargeting or lookalike audiences is tracking.
• Adding an SDK that combines your app's data with data from other apps is tracking, even if you don't use it for that purpose.

In contrast, linking that happens solely on the device and never leaves it in an identifiable form does not count. Using a data broker solely for fraud prevention or security also falls outside the definition.

If you track, guideline 5.1.2 of the App Store Review Guidelines requires explicit permission through App Tracking Transparency (ATT). We covered how the ATT prompt affects ad measurement in our App Tracking Transparency (ATT) guide. Here, we focus only on how it shows up in the label.

How do you choose the purposes for each data type?

For each data type, you pick one or more purposes. Apple's list has six headings:

1. Third-Party Advertising: showing other companies' ads in your app, or sharing data with entities that show those ads.
2. Developer's Advertising or Marketing: showing your own ads, or sending marketing messages directly to your users.
3. Analytics: evaluating user behavior, understanding feature effectiveness, and measuring audience size.
4. Product Personalization: customizing what the user sees, such as recommended products or posts.
5. App Functionality: authentication, fraud prevention, security, server uptime, fewer crashes, and customer support.
6. Other Purposes: any use not on the list.

Above all, honesty pays off here. For example, if you use the email address for both login and a promotional newsletter, you select both purposes. If you choose only App Functionality and hide the newsletter, your product page will not reflect reality. Moreover, a reviewer who sees a newsletter checkbox in your app will notice the gap.

One more tip: you choose purposes per data type, not per app. So saying "our app does analytics" is not enough; you mark which data feeds analytics. One data type can have several purposes, and the same purpose can repeat across types. That repetition is normal and gives users a clearer picture.

When is disclosing a data type optional?

Apple makes disclosure optional in a few narrow cases. However, the general exception applies only when you meet every one of these conditions at the same time:

• You do not use the data for tracking.
• You do not use it for Third-Party Advertising, your own advertising or marketing, or Other Purposes.
• Collection is infrequent, not part of the app's primary functionality, and optional for the user.
• The user provides the data in your interface, sees clearly what goes out, has their name or account name shown prominently on the form, and chooses to submit it each time.

Sample scenario: an occasional "send feedback" form inside the app may fit this description. In contrast, data you keep collecting after an initial permission request does not qualify; Apple wants you to disclose it.

Apple also lists separate conditions for product improvement programs, regulated financial services notices, and approved research studies. If you fall into one of these, check each condition on the official page. If even one condition is missing, you disclose the data. In short, when in doubt, disclosing is always safer than leaving something out.

How do third-party SDKs affect your label?

In practice, every library you add can collect data on your behalf. Apple's third-party SDK requirements page says it plainly: when you use an SDK, you are responsible for all the code it brings into your app. Therefore, every analytics, crash reporting, advertising, push notification, and payment kit goes into your inventory.

Our routine is simple, so it scales to any project. We export the dependency list, open each SDK's own privacy documentation and privacy manifest, and then put the data types it collects into the table. As a result, the "we don't collect that" misconception disappears, because the collecting code runs inside your app.

The same SDK can also collect different data depending on its settings. For instance, if you turn off advertising ID collection in an analytics kit, your Device ID answer may change. So document SDK settings in code and match them to your label answers.

If you are building a new app, setting up this inventory early is much easier. At Talha Aslan and team, our mobile app development projects plan SDK choices together with the privacy disclosure, and we handle the store release for you. Feel free to request a quote for your project.

What is a privacy manifest?

A privacy manifest is a property list file that records the data types an app or third-party SDK collects and the required reason APIs it uses. The file must carry the name PrivacyInfo.xcprivacy. Apple explains the structure in its Privacy manifest files documentation.

Specifically, the manifest holds four main keys at the top level:

• NSPrivacyTracking: a Boolean that says whether the app or SDK uses data for tracking as ATT defines it.
• NSPrivacyTrackingDomains: the list of internet domains that engage in tracking. If the user has not granted tracking permission, requests to these domains fail.
• NSPrivacyCollectedDataTypes: dictionaries that describe the data types the app or SDK collects.
• NSPrivacyAccessedAPITypes: dictionaries that list the required reason API categories it accesses and the reasons.

The manifest does not replace the label in App Store Connect. Still, the two connect directly: when you prepare to distribute, Xcode combines the manifests of your third-party SDKs into a single report. That report helps you answer the label questions more accurately. In other words, the manifest works as a reliable checklist for the label.

Why do required reason APIs matter?

You use some APIs for ordinary features. However, the same APIs can open the door to fingerprinting, which tries to identify a device or person from device signals. Apple's documentation is clear: fingerprinting is not allowed, even if the user grants tracking permission.

So if you use one of these API categories, you declare a matching approved reason in your manifest. According to the documentation, App Store Connect does not accept apps that use required reason APIs without describing the reason in the manifest. Apple also sends you a reminder email when the reason is missing.

There is also one more detail. An SDK has to report its own usage in its own manifest; it cannot rely on your app's manifest. Apple also publishes a list of commonly used SDKs. When a new app or an update adds a listed SDK, you include that SDK's manifest, plus its signature if you use it as a binary dependency. Check the current list on the official page.

How do you enter App Store privacy labels in App Store Connect step by step?

The flow on Apple's App Store Connect Help page runs in this order. Menu names can change over time, so if your screen shows different wording, follow the official help page.

1. Open Apps and select your app.
2. In the sidebar, open App Privacy.
3. Click Get Started on the right to begin.
4. Answer whether you or your third-party partners collect data. If you don't, select that option and save.
5. If you do, select every data type you and your partners collect, then save.
6. In the Data Types section, click each type and answer the purpose, linking, and tracking questions.
7. Review the look of your product page in Product Page Preview.
8. Click Publish at the top right and confirm accuracy in the dialog.

If your app is already live, Apple asks you to select only the data that version collects. Don't disclose today for a feature that ships next month. Instead, update the label in the release that launches the feature.

Sample scenario: what does a food ordering app's label look like?

The table below is a sample scenario we built for a fictional food ordering app. It does not belong to a real client; it only shows the reasoning.

The last row changes the tone of the whole label. If the ad SDK combines the device ID with data from other apps, your product page gains a separate section for tracking data, and ATT permission becomes mandatory. So weigh that outcome with your product team before you add an ad SDK.

Do privacy labels affect download decisions?

First, the label appears on your product page, and users can review it before they download. As a result, it works like part of your store listing. A long data list, especially with a full tracking section, may give some users pause. However, no official data puts a number on this effect, and we don't claim one.

The right approach is to collect less unnecessary data, not to shrink the label artificially. For example, removing an analytics event you never use simplifies the label and lightens the app. Also, you can strengthen screenshots, descriptions, and keywords with the approach in our App Store Optimization (ASO) guide.

How should the label match your privacy policy?

Guideline 5.1.1 of the Review Guidelines asks every app to link its privacy policy in the App Store Connect metadata field and inside the app in an easily accessible way. The privacy policy URL is required. A URL where users can manage their privacy choices is optional.

Consistency also matters here. If the label shows purchase history but your policy never mentions it, users and reviewers read two different stories. That's why the label, the policy, and your in-app permission texts should all come from the same data inventory.

Depending on where your users live, privacy laws add notice and consent duties. We covered that side in our mobile app privacy compliance guide. Note: this guide is not legal advice; finalize your texts with your legal counsel.

Which mistakes do we see most often in App Store privacy labels?

In practice, the same mistakes repeat across the store projects we support. The list below shows what we check first:

• Forgetting SDKs: listing only the data your own server receives and skipping analytics or crash kits.
• Choosing "not linked to the user" without a technical basis.
• Disclosing email only for login and leaving out marketing sends.
• Missing the data that forms inside web views collect.
• Leaving contradictions between the label and the privacy policy.
• Adding a feature and never updating the label.

Some of these mistakes can turn into rejection reasons during review. We gathered the broader picture in our article on the most common app rejection reasons. If your app offers account creation, also read about Apple's mandatory account deletion rule, because the deletion flow ties naturally to your privacy choices page.

When should you update App Store privacy labels?

Apple holds you responsible for keeping your answers accurate and up to date. When your practices change, you update the answers in App Store Connect. The good news: you don't need to submit an app update to change them. Once you edit and click Publish, the product page information changes too.

There is one distinction, though. Changes to the privacy policy URLs go live with your next app version. In addition, guideline 2.3 asks that all metadata, including privacy information, accurately reflect the core experience and stay current with new versions. Typical triggers include:

• You added a new SDK, or a new version of an existing SDK collects different data.
• You started asking for a new data type, such as a profile photo or location.
• The purpose of existing data grew; for example, analytics data now drives personalization too.
• You launched an ad or retargeting campaign.
• You removed a feature or SDK and no longer collect that data.

We suggest adding a short "privacy impact" line to every release note. That way, the need to update the label surfaces naturally during release prep. For instance, if the note says "added a new analytics SDK," the same line tells you which data type changed, so you remember to open App Privacy before launch.

How is it different from the Google Play Data safety form?

Both stores ask similar questions, but they phrase them differently because each uses its own policy language. If you also ship an Android version, the healthiest path is to prepare both disclosures from one data inventory. We walked through the Google side step by step in our Google Play Data safety form guide.

The core difference is terminology. Apple centers its questions on tracking and linked data, while Google uses its own definitions in its form. So instead of copying your Apple answers as they stand, read each question through that store's definitions. On the other hand, your inventory stays shared; only the shape of your answers changes.

Which checklist should you use before release?

If you follow this order before submission, your label, manifest, and policy will speak the same language:

1. Export the dependency list and check each SDK's privacy manifest.
2. Create your app's own manifest and record each required reason API with its reason.
3. Note which identifier travels with every event your server receives.
4. Write purposes, linking status, and tracking answers for each data type into the table.
5. If you track, test the ATT prompt and the behavior when users decline.
6. Compare your privacy policy against the table and resolve contradictions.
7. Enter the answers in App Store Connect, check Product Page Preview, then publish.

Testing on real devices also makes this easier. To try a build with internal testers before submission, see our TestFlight guide. Also, watching network traffic during testing helps you catch an unexpected SDK call early.

How can Talha Aslan and team help with privacy readiness?

Put simply, label preparation is a byproduct of app architecture. The SDKs you pick, the identifiers you send with each event, and the timing of each permission request decide the outcome. That's why we don't leave privacy for launch day; we map the data inventory with you during the design phase.

If you are planning a new app or want to get an existing one store ready, our mobile app development service covers development, the privacy disclosure, and store submission together. Share your project scope and we'll prepare a tailored quote. Store rules can change, so we recheck current Apple documentation on every project; nothing here guarantees approval.