App Store privacy: policy and data labels

What reviewers check

1. Accessible policy information

   Reviewers require an accessible in-app policy link as well as App Store Connect policy metadata.

   Official source: Apple: Guideline 5.1.1

2. App and SDK data practices

   Privacy answers cover your own code and integrated partners. Inventory both before selecting labels.

   Official source: Apple: Privacy questions

3. Tracking and permission

   If your practices meet Apple’s tracking definition, applicable ATT permission requirements are separate from publishing privacy labels.

   Official source: Apple: Tracking permission

Documented rejection risks

1. Broken or incomplete submissions

   Apple explicitly rejects incomplete or crashing apps. Working links and reviewer access matter.

   Official source: Apple: Guideline 2.1

2. Labels that omit collection

   Optional disclosure is conditional, not a blanket exemption for optional features or SDKs. Check every criterion.

   Official source: Apple: Optional disclosure

3. Obstructed account deletion

   Apps with account creation must offer deletion initiation in-app. Unnecessarily difficult deletion will not pass review.

   Official source: Apple: Account deletion guidance

Submission checklist

1. Build the data inventory

   List the app’s own components and each integrated SDK, with the version and configuration you intend to ship. For every component, identify collected data and how it is used. Consult provider documentation and inspect available privacy-manifest information; treat missing answers as open questions rather than assuming the SDK collects nothing.

   Official source: Apple: Describing data use

2. Classify each data type

   Compare the confirmed inventory with Apple’s named data types instead of copying a generic label set. Record a proposed type for each field and flag ambiguous cases for review. For example, Apple’s Email Address category includes hashed email addresses: transforming a value does not automatically remove it from the disclosure inventory.

   Official source: Apple: Data types

3. Explain retention and deletion

   Place an accessible policy link inside the app and provide the required policy metadata in App Store Connect. Explain the actual collection, uses, third-party protection and retention/deletion practices. Check that the described consent-withdrawal and deletion routes exist before promising them; policy prose is a description of behavior, not its implementation.

   Official source: Apple: Guideline 5.1.1

4. Check ATT separately

   Assess the app and each SDK against Apple’s tracking definition. When ATT permission is required, integrate the framework and an appropriate purpose string, then verify behavior when permission is denied. Do not treat a privacy label, website cookie banner or another consent prompt as permission to perform tracking that requires ATT.

   Official source: Apple: Using ATT

5. Enter and publish privacy answers

   In App Store Connect, select the app and open App Privacy. Answer whether you or integrated partners collect data, add the confirmed types and complete the follow-up questions. Save the responses and publish the information. Review the resulting presentation against your inventory; entering answers without completing publication is not the final artifact.

   Official source: Apple: Entering privacy answers

6. Review changes before release

   Before changing an SDK or data-handling feature, compare the new behavior with the published privacy responses. Update changed answers in App Store Connect and publish them. Account for differences across the app’s platforms rather than describing only the least data-intensive version. Keep a dated internal inventory so a later reviewer can reconstruct the decision.

   Official source: Apple: Updating privacy responses

Example

1. Fictional app: Harbor Notes

   Fictional input: Harbor Notes stores an account email and account identifier for sign-in, and sends crash events to an integrated SDK. Assume the email is associated with the account and used for app functionality, not advertising. The owner records those assumptions in an inventory row, then creates a separate SDK row with its version and configuration. Crash fields, identifiers, retention and downstream uses remain unconfirmed until reviewed. Expected artifact: a two-row inventory separating known account behavior from unknown SDK behavior. This is a hypothetical worksheet, not a ready-to-submit privacy label.

   Official source: Apple: Describing data use

2. Complete the owner’s worksheet

   Fictional input: the account implementation confirms the previous assumptions, while the crash provider’s documentation reveals optional user identifiers whose deployed setting is still unknown. The owner proposes Email Address, app functionality and linked-to-user answers for the account email, then asks engineering to inspect the SDK setting before completing its row. No “not linked” or “no tracking” answer is inferred from the phrase crash reporting. Expected artifact: confirmed account answers plus an explicitly unresolved SDK assessment; publication waits for the missing facts rather than silently converting unknowns into negative answers.

   Official source: Apple: Privacy questions

3. Test the fictional account flow

   Fictional input: Harbor Notes lets people create accounts and provides Settings → Account → Delete account. A synthetic tester opens that path, confirms the request and sees an explanation of any processing delay. The test checks the resulting account state and associated test data against the deletion promise. Expected artifact: a short test record containing the initiation path, confirmation screen and verified outcome. Merely disabling sign-in is not assumed to be deletion. Any retention required by law needs a real, explained basis; this fictional example does not supply one.

   Official source: Apple: Account deletion guidance

https://harbor.example/privacy
https://harbor.example/privacy-choices

Frequently asked questions

1. Is a privacy-choices URL mandatory?

   No. That URL is optional. Policy requirements vary by platform: iOS uses a policy URL; tvOS provides policy text.

   Official source: Apple: Platform policy requirements

2. Is every analytics use tracking?

   No. Assess Apple’s definition against actual data combination, advertising measurement and broker sharing, including SDK behavior.

   Official source: Apple: Tracking definition

3. Can deletion require contacting support?

   Generally not outside highly regulated industries. Apple distinguishes those exceptions from ordinary apps and allows reasonable identity confirmation.

   Official source: Apple: Account deletion FAQ