Skip to content
Privacy tools

iOS App Tracking Transparency and your privacy policy

Policy generation is paused. Check your existing policy against your website.

Prepare a consistent privacy policy, ATT flow and App Store disclosure. Start with your app’s public site and use the checklist to review its native data flows.

Updated 1 Oct 2026 against Apple developer guidance

Start with your website

I have the link to my privacy policy

Optional. If you paste the direct link, we read that page instead of looking for it, so the check is more exact.

By scanning, you confirm that you own this website or are authorized to test it, and you agree to our Terms.

No account needed.

What to account for

  1. Decide whether the activity is tracking

    Apple includes linking app and third-party data for targeted ads or advertising measurement, and sharing with data brokers. Review each SDK.

  2. Request authorization before tracking

    Use AppTrackingTransparency for authorization and include NSUserTrackingUsageDescription to explain the request. Check the returned authorization status before enabling tracking behavior.

  3. Keep App Store privacy details aligned

    Your App Store privacy answers include data collected by third-party partners whose code you integrate. Review tracking, data linked to users and the published privacy policy together.

Common mistakes to check

  1. Treating website consent as ATT permission

    A website consent choice does not override a denied ATT decision in the app. Honor the platform authorization result.

  2. Replacing a denied identifier with fingerprinting

    Apple prohibits deriving device information to uniquely identify a device or user. A different identifier is not a workaround for denied tracking permission.

Your review checklist

Our suggested review process. The linked requirements above explain the platform or legal basis.

  1. Map native and web data flows

    Scan the public app website, then inspect native SDK configuration, network traffic and partner contracts. Separate first-party analytics, advertising and cross-company sharing by purpose.

  2. Review all permission states

    Test fresh installation, refusal, approval and a later settings change. Confirm when tracking SDKs start and what happens to collected data in each state.

  3. Publish a consistent set of disclosures

    Review the draft policy, ATT purpose string and App Store privacy answers side by side. Keep a release checklist for SDK additions and changes in data recipients.

Example

  1. An app adding advertising attribution

    A fictional fitness app adds an attribution SDK. The team checks whether its configuration links user data across companies, rather than deciding from the SDK’s name alone.

  2. Review before the release

    Where the chosen activity requires ATT, the team gates it on authorization, tests refusal and updates the policy and App Store answers before submitting the release.

Questions before publishing

  1. Does every analytics tool require ATT?

    It depends on actual data use and Apple’s tracking definition.

  2. Does the ATT prompt replace privacy details?

    No. App Store privacy details describe collection and uses, including relevant third-party practices; they remain a separate disclosure.

  3. Where does the app read the decision?

    The AppTrackingTransparency API exposes trackingAuthorizationStatus and the authorization request result. Use those states in the app’s behavior.

Source review and changes

First edition: platform requirements, implementation checks and fictional worked example. Sources reviewed on the date above; verify changes before relying on them.