Apple's App Privacy Nutrition Label: How to Fill It Out

The first time you reach the App Privacy section in App Store Connect, it feels like a pop quiz you didn't study for: dozens of data types, "linked to identity" toggles, tracking questions, and no obvious way to know if you're answering correctly. Get it wrong and you risk a rejection — or worse, a mismatch that Apple flags after launch. This guide demystifies the app privacy nutrition label so you can fill it out accurately and move on.

The short version: the privacy label is a questionnaire in App Store Connect that generates the "food-label" style privacy summary on your App Store listing. It's required for every app, even ones that collect nothing, and it must match your written privacy policy. Here's how to complete it without guessing. If you're not sure whether you even need a privacy policy behind it, start with do I need a privacy policy for my app.

What is the app privacy nutrition label?

Apple's App Privacy label (officially the "App Privacy" section, informally the "privacy nutrition label") is the summary of your data practices shown on your App Store product page. It's styled like a nutrition label on food packaging — a scannable breakdown of what data your app collects, grouped into categories so users can understand your privacy practices before they download.

You don't design it. You answer a questionnaire in App Store Connect (under your app → App Privacy), and Apple renders the label from your answers. It's the App Store counterpart to Google Play's Data Safety form — if you're publishing to both stores, see how to fill out Google Play's Data Safety section, because the two must tell the same story.

Is the privacy label required?

Yes — with no exceptions. Every app must complete the App Privacy questionnaire before submission, including apps that collect no data whatsoever. If your app genuinely collects nothing, you declare "Data Not Collected," and your label simply reflects that. There's no way to skip the section and still submit.

The three questions Apple actually asks

The whole questionnaire boils down to answering three things about each type of data:

Do you collect it? "Collect" means the data leaves the device in a way you or a third party can access — including through your analytics or ads SDKs, not just your own code.
Is it linked to the user's identity? Data is "linked" if it's tied to a user account, device ID, or other identity. The same data can be collected but not linked if it's fully anonymized.
Is it used to track the user? "Tracking" has a specific Apple meaning: linking your data with data from other companies for advertising or sharing with data brokers. This is the question tied to App Tracking Transparency.

For each data type you collect, you also declare why — the purpose (app functionality, analytics, product personalization, advertising, etc.).

Data categories you'll be asked about

Apple groups data into categories. You don't need to memorize all of them, but you do need to recognize which ones apply to your app. The most common for indie and no-code apps:

Category	Common examples	Do most apps collect it?
Contact Info	Name, email, phone number	Yes, if you have accounts
Identifiers	User ID, device ID	Often (accounts, analytics)
Usage Data	Taps, screens viewed, interactions	Yes, if you use analytics
Diagnostics	Crash logs, performance data	Often (crash reporting)
User Content	Photos, messages, files users create	Depends on the app
Location	Precise or coarse location	Only if you use it
Purchases	Purchase history	If you sell anything
Financial Info	Payment info	Rarely (usually handled by Apple/Stripe)

The trap here is third-party SDKs. If you use an analytics tool, a crash reporter, an ads network, or a login provider, their data collection counts as yours. Check what each SDK collects — the vendor's own privacy documentation usually spells it out — and declare it.

For no-code makers, this is worth pausing on. You may not have written a single line that touches user data, but the platform and services your app relies on almost certainly collect some. Common examples: an analytics integration recording usage data, a crash reporter capturing diagnostics, a sign-in provider handling contact info and identifiers, and any push-notification service using a device token. Treat every integration as a potential data collector until you've confirmed otherwise, rather than assuming "I didn't build it, so I don't collect it."

Step-by-step: filling it out in App Store Connect

Go to App Store Connect → your app → App Privacy and click Get Started (or Edit).
Answer whether your app collects data at all. If no, declare Data Not Collected and you're done.
For each data type you collect, select it from Apple's list.
For each selected type, choose the purpose(s) — app functionality, analytics, personalization, advertising, and so on.
Declare whether each type is linked to the user's identity.
Declare whether each type is used for tracking.
Review the generated label preview, save, and publish. The label updates on your live listing (some changes require a new app version, others publish independently).

Take your time on step 3 — under-declaring is the mistake that causes rejections, and over-declaring makes your app look more invasive than it is.

How to avoid rejections and mismatches

The two ways the privacy label gets you in trouble are inaccuracy (Apple catches you collecting something you didn't declare) and inconsistency (your label contradicts your written privacy policy). Avoid both:

Inventory your data first. Before you open the questionnaire, list every piece of data your app touches, including everything your SDKs collect. Answering from a list beats answering from memory.
Match your privacy policy exactly. Your label and your written policy must describe the same practices. The cleanest way to guarantee this is to generate both from the same understanding of your data — the app privacy policy generator produces a hosted policy you can align your label to, and it doubles as the URL both stores require.
Don't forget "tracking." If you run ads or share data with third parties for advertising, you must declare tracking and implement App Tracking Transparency. Getting this wrong is a common rejection reason.
Re-check after adding SDKs. Any time you add a new integration, revisit your label — new tools often collect new data.

A wrong label isn't a small mistake. It can get your submission rejected during review, and if Apple finds a mismatch after launch, they can require a fix or pull the app. It's worth the extra 20 minutes to get right.

Where it fits in your submission

The privacy label is one item on a longer list of things Apple checks before your app goes live. Slot it in alongside your privacy policy URL, screenshots, and metadata using our app store submission checklist so nothing slips through. And if you're publishing a no-code app and want the full walkthrough, the pillar on how to publish an app without code covers where the privacy label sits in the end-to-end flow.

If cost is a concern, note that a compliant privacy policy — the document your label has to match — can be produced for free or a one-time unlock; the Adalo Studio pricing page breaks down exactly what that involves.

Frequently asked questions

What is Apple's app privacy nutrition label?

It's the App Privacy section on your App Store product page that summarizes what data your app collects and how it's used, shown in a food-label-style format. You fill it out in App Store Connect by answering a questionnaire before you submit your app for review.

Is the app privacy label required?

Yes. Every app submitted to the App Store must complete the App Privacy questionnaire in App Store Connect, even if your app collects no data at all. If you collect nothing, you simply declare 'Data Not Collected' and the label reflects that.

What happens if my privacy label is wrong?

An inaccurate label can get your submission rejected during review, and if a mismatch is found later Apple can require you to fix it or remove the app. Your label must also match your written privacy policy, so both should be generated from the same understanding of what your app actually collects.

Tools mentioned in this guide: App Store Screenshot Generator, App Privacy Policy Generator.