App Store privacy nutrition labels for subscription apps: what to declare, what gets flagged, and how transparency affects conversion

A practical guide to App Store privacy nutrition labels for subscription iOS apps — covering required data types, common declaration mistakes, App Store review pitfalls, and what privacy transparency means for trial-start conversion.

Privacy nutrition labels appeared on the App Store product page in December 2020, and they have been required for every new app and every update ever since. For subscription app developers they sit at an awkward intersection: you need to declare enough data to be accurate — or face rejection — yet a long list of categories can give potential subscribers pause before they even tap “Get”. Understanding what to declare, and why, is now table stakes for subscription app operations.

What App Store privacy nutrition labels actually show

Before a user downloads your app, the App Store product page surfaces three sections under the “App Privacy” heading:

• Data Used to Track You — data linked to identities that is shared across third-party apps and websites, typically for advertising purposes.
• Data Linked to You — data collected and associated with your Apple ID or a device-level identity.
• Data Not Linked to You — data collected but not tied back to identity (often diagnostic or analytics data collected with anonymisation applied).

A fourth state — Data Not Collected — only appears if none of the above applies. Achieving this label legitimately is rare for subscription apps, because nearly all subscription management requires a user identifier of some kind.

The labels are self-reported: Apple does not audit them automatically at submission time, but the company does review them for consistency with declared SDK usage and with the capabilities evident in the app binary. Inconsistencies are among the most common causes of App Store review rejection.

Data types subscription apps most commonly declare

Subscription apps have a characteristic data fingerprint that differs from, say, a casual game. Because they manage recurring billing, communicate with users around renewals, and often personalise onboarding, they tend to collect more data categories than the average free app. The table below maps the categories Apple defines to typical subscription app usage patterns:

If you use a subscription management SDK such as RevenueCat, Adapty, or Purchasely, their documentation lists what data each SDK collects and how to represent it in your privacy label. Checking those docs before completing your label is worth the time: SDK authors are required to publish privacy manifests, and this is now the canonical reference for your dependency graph.

How to fill in your privacy nutrition label in App Store Connect

The label is edited under App Information → App Privacy in App Store Connect. For each category you enable, you select three things:

1. Purpose — why you collect this data: app functionality, analytics, product personalisation, developer’s advertising or marketing, third-party advertising, or other.
2. Linked to identity — yes or no. “Yes” moves the category into the “Data Linked to You” section visible to users.
3. Used for tracking — yes or no. “Yes” moves it into “Data Used to Track You”, which Apple treats more strictly under the App Tracking Transparency (ATT) framework.

A few practical notes that come up repeatedly among developers who have worked through this:

• Third-party SDKs count. If your attribution partner sends device identifiers to their own servers, that data is being collected even if your own code never touches it. You are responsible for declaring it.
• Aggregate or anonymised data may qualify as “Data Not Linked to You” — but only if the anonymisation is robust and applied before any join to a user identifier. Apple’s guidance suggests that data joined to a user ID at any point in the pipeline should be treated as linked.
• Optional data is still declared data. If your app offers optional sign-in with Google or optional location features, you must declare those data types even though not all users trigger them.
• Privacy manifests (introduced in 2023) are now the source of truth. Apple’s required reasons APIs and SDK privacy manifest files feed directly into what should appear on your nutrition label. Keeping manifests up to date means your label stays accurate automatically.

Once submitted, changes to the label take effect immediately for new users browsing the App Store — you do not need to push a new app binary to update it. However, if a label change reflects a genuine addition of data collection in a new SDK, it should accompany an app update so the binary and the label stay in sync.

For apps that operate across the EU, accurate data declarations also interact with GDPR obligations and your App Store listing requirements in those territories. See our overview of EU Digital Markets Act obligations for iOS subscription developers for the regulatory context that sits alongside your privacy label.

What App Store review flags — and how to avoid rejections

App Store review does not automatically cross-reference your label against every framework in your binary, but reviewers do inspect for obvious inconsistencies during manual review. The rejections developers report most frequently in this area involve a small number of patterns:

• ATT prompt present but no tracking data declared. If your app calls the ATT permission dialog, reviewers expect to see at least one category under “Data Used to Track You”. An ATT prompt with nothing in that section is an immediate red flag.
• Attribution SDKs not declared. Adjust, AppsFlyer, and Branch all collect device-level identifiers for cross-app measurement. Include them and declare nothing in the device ID or tracking category and expect a rejection note.
• Email collection omitted. Apps offering email sign-in or sending renewal reminder emails need to declare email address under “Data Linked to You” with the purpose “App Functionality” at minimum. This includes Sign in with Apple flows where the email relay is used.
• Purchase history missing from a StoreKit app. Any app using StoreKit needs to declare purchase history. Entitlement management inherently involves purchase record access, and reviewers are aware of this requirement.

When a rejection arrives, Apple’s Resolution Center typically includes a note under the “App Privacy” metadata section. The fastest path to resolution is updating the label to match actual behaviour, not removing the SDK from your app to make the label technically accurate but your analytics incomplete. A consistent label that correctly describes what you collect is more valuable than a minimal label that understates it.

How privacy labels affect subscription conversion

This is the area where evidence is most nuanced. User research on privacy label awareness — including studies published in academic and industry contexts — suggests that users do notice the label when it is prominent, particularly users who already have stated privacy concerns. However, the majority of App Store downloads happen without users expanding the privacy detail section at all.

What may matter more in practice is contrast with nearby competitors. If your category peers show shorter labels while yours lists a full set of categories including tracking data, that contrast becomes visible when users compare product pages. ASO practitioners have observed anecdotally that removing inactive attribution SDKs — legacy integrations from ad networks that no longer receive spend — can shorten a label without compromising active measurement.

For the subscription funnel specifically, the privacy label is most visible before the install decision, which places its effect at the same stage as screenshots and star ratings. If you are running product page optimisation experiments, the privacy label is not a variable accessible through Custom Product Pages — it is fixed across all variants. This means any improvement to the label requires an SDK audit and an app update, not a quick metadata test. See our guide to App Store product page optimisation for subscription apps for the variables that are testable through CPP.

A few practical actions subscription developers have taken to reduce their label surface area without compromising analytics or attribution quality:

• Audit inactive attribution SDKs. Dead code collecting data for a network you no longer run ads on is pure label overhead. Removing it shrinks the label and eliminates a potential rejection vector.
• Use SDK privacy modes where available. Some analytics tools offer a mode that anonymises data before transmission, potentially moving usage data from “Linked to You” to “Not Linked to You”. Verify with the vendor before making this declaration.
• Consolidate redundant integrations. Developers who have shipped across multiple product generations sometimes maintain crash reporters and analytics libraries from different eras. A single well-configured tool generally covers the same ground with a smaller data footprint.

For further context on how App Store subscription architecture decisions interact with compliance requirements, see our overview of iOS subscription group design. The group and tier choices you make early tend to determine which data flows you need to track, which in turn shapes your privacy label.

Sources and further reading

• Apple Developer — App privacy details on the App Store: official definitions of each data category, purpose type, and how the label sections map to them.
• Apple Developer Documentation — Privacy manifest files: required reasons APIs, SDK manifest requirements, and how they interact with your nutrition label.
• App Store Review Guidelines (section 5.1): the policy text reviewers use when evaluating label accuracy and data collection practices.
• RevenueCat documentation: SDK-specific guidance on data collection, privacy manifest contents, and what to declare for apps using RevenueCat for subscription management.
• Phiture Mobile Growth Stack: ASO and product page best practices, including metadata compliance considerations for subscription apps.
• Apple Privacy Labels — consumer overview: the consumer-facing explanation of what labels mean, useful context for understanding what potential subscribers see before download.