Apple Developer Privacy Manifest Guide for Apps

A privacy manifest is not a privacy policy, and it is not a box to check before a release. It is a machine-readable statement inside your app that tells Apple why the code uses certain APIs and what data-related behavior comes from included SDKs. This Apple developer privacy manifest guide focuses on the part that causes real release friction: making the declaration match the product, the code, and every dependency you ship.

For a small team, the goal is simple: know what your app accesses, collect less, and make every declaration defensible. The paperwork gets easier when the architecture is honest.

What an Apple privacy manifest actually does

Apple privacy manifests live in a `PrivacyInfo.xcprivacy` file. The file can declare four things: whether the app uses data for tracking, the domains it contacts for tracking, the data types it collects, and its use of required-reason APIs. It can also be packaged by third-party SDKs so the SDK states its own behavior.

The most commonly discussed part is required-reason APIs. Apple identifies certain APIs that could be used to infer behavior or identify a device in ways users would not reasonably expect. If your app or included code calls one of those APIs, you must provide an approved reason for using it. The reason must describe the app's actual function, not a convenient sentence that makes review pass.

Platform scope matters. Apple's required-reason API rules apply to apps for iOS, iPadOS, tvOS, visionOS, and watchOS. Since May 1, 2024, App Store Connect does not accept new or updated apps for those platforms that use a listed API without an approved reason, and the upload triggers an email (ITMS-91053) naming what is missing. A macOS app can include a privacy manifest, but it is not required to declare required-reason APIs. If you ship on both iOS and macOS from shared code, treat the iOS requirement as the baseline so the declarations stay accurate everywhere.

This is separate from App Store privacy disclosures. The App Store listing asks what data your app collects and how it is used. The manifest gives Apple and its tooling a more concrete view of API access and dependency behavior. They should agree, but they serve different jobs.

Start with the product behavior, not the plist

Do not begin by copying a manifest from another project. Begin with a short data map. Write down what the app receives, stores, transmits, and deletes. Then identify which parts happen on-device, which calls leave the device, and which third parties are involved.

A focused macOS utility might read selected text only after a user action, process it locally, and show a result in its own panel. That is materially different from a utility that uploads every keystroke to a remote service. Both may have a similar-looking interface. Their privacy manifests, App Store disclosures, network behavior, and user explanations should not look the same.

At uAgency, privacy-first defaults are a product decision. For example, uChecker processes selected text on the device by default through Apple Intelligence or the offline spell-checker. Its optional custom endpoint, available with Pro, can send checked text to an OpenAI- or Anthropic-compatible service the user configures. That exception needs clear product copy and accurate technical review. A manifest cannot make an unclear data flow acceptable.

Find required-reason API use across the whole build

Required-reason APIs are easy to miss because the call may not be in your application target. It may sit in a package, framework, analytics library, crash reporter, or inherited utility code. Treat the final archive as the product, not just the source files your team wrote this week.

Start by searching application code for Apple’s current list of required-reason API categories. Common areas include access to user defaults, file timestamps, disk space, system boot time, and active keyboard information. The exact categories and approved reason codes can change, so use Apple’s current documentation and Xcode validation output before each release cycle.

Then inventory dependencies. For each package or binary framework, answer three practical questions: does it include a privacy manifest, does that manifest describe the SDK you actually use, and is the version current enough for Apple’s SDK signature requirements? A dependency with a manifest is not automatically safe. It may declare capabilities your configuration does not use, or it may have changed behavior after an update.

If you ship a framework yourself, include its manifest with the framework rather than relying on each consuming app to guess. Library authors are closest to the code. Make their work visible.

Choose reasons that match the feature

Approved reason codes are deliberately narrow. That is the point. If a feature reads a preference to preserve a user setting, select the reason that reflects preference storage. Do not select a broadly worded reason because it sounds adjacent.

A good internal test is whether you could explain the selection in one plain sentence to a customer: “We use this API to retain the setting you chose.” If the sentence feels evasive, revisit the design. Sometimes the answer is a different API. Sometimes it is removing an unnecessary signal altogether.

Avoid treating required-reason declarations as permission prompts. They do not grant access. User-facing permissions, entitlements, sandbox rules, and platform APIs still apply. The manifest explains why certain designated APIs are present in the shipped software.

Keep third-party SDKs on a short leash

Many privacy problems enter through dependencies added for convenience. A small SDK can bring telemetry, identifiers, remote configuration, or domains your product team did not intend to contact. “We do not use it directly” is not a useful defense if it is bundled into the app.

Keep a dependency register with the package name, version, owner, purpose, data behavior, privacy manifest status, and review date. This does not need to become a bureaucracy. A simple file reviewed before releases is enough for many teams. What matters is that someone owns each dependency.

Remove SDKs that do not earn their place. If an SDK is only needed in development, do not ship it in production. If a service can work without a device-level identifier, configure it that way. If a feature needs a network request, state the request clearly in the product and make the destination predictable.

Apple’s SDK signatures add another layer of supply-chain verification for certain commonly used SDKs. Signatures and manifests solve different problems. A signature helps establish that the SDK came from its expected developer and was not altered. A privacy manifest describes declared behavior. You need both when Apple requires them.

Build the manifest as part of release work

Add the `PrivacyInfo.xcprivacy` file to the correct target and confirm it is copied into the final app bundle. A manifest sitting in the repository but excluded from the release target is no help.

Use Xcode’s privacy report and archive validation as early signals, not last-minute alarms. Run them on release candidates, especially after dependency updates. A clean local build is not proof that a submitted archive will satisfy every App Store check, but it catches many preventable mistakes.

Before submission, review the release as a customer would. Inspect the app’s settings, permission prompts, network requests, and App Store privacy answers together. If the app says it is local-first but opens an unexpected connection, fix the mismatch. If a feature sends a city to a weather provider, say so. For example, uNotch’s optional Weather page sends a city to Apple’s MapKit and WeatherKit. That is a narrow, user-directed exception, but it still deserves plain language.

Apple developer privacy manifest guide: a practical release check

Before you upload a build, verify four areas:

• The final app target contains a current privacy manifest, and each shipped SDK is inventoried.
• Every required-reason API reported by your tools has an approved reason tied to a real feature.
• Your App Store privacy answers, privacy policy, onboarding copy, and actual network behavior tell the same story.
• Dependency versions meet Apple’s current manifest and signature expectations, with no unused SDKs left in the archive.

This check is intentionally modest. It catches the failures that create review delays and, more importantly, the gaps users notice later.

Do not overdeclare to feel safe

A common instinct is to declare every possible data type, reason, and domain just in case. That creates its own problems. Broad declarations can contradict your App Store answers, confuse reviewers, and make customers assume your app does more tracking than it does.

Be precise instead. Privacy manifests reward teams that understand their own software. If you do not know why a framework reads a value or contacts a domain, that is not a documentation problem. It is an engineering question worth answering before release.

Apple’s requirements will keep evolving, particularly around SDK supply chains and sensitive platform signals. The durable response is not a one-time compliance sprint. Build a release habit where product decisions, code, and disclosures stay close together. Private by default is easier to maintain when the app remains small enough to explain.