# App Tracking Transparency: when your iOS app must ask to track > Learn when iOS apps need ATT, how to audit SDK data flows, and where consent fits in a production release. > By Dave · 2026-10-11 > Source: https://otf-kit.dev/blog/ios-app-tracking-transparency-permission ## The decision to make before adding an analytics SDK An iOS app does not need App Tracking Transparency (ATT) merely because it contains analytics, advertising, attribution, or crash-reporting code. The relevant question is what the app does with data about people: does it collect that data and share it with another company to track people across apps or websites? Apple’s App Tracking Transparency documentation says an app needs to use the framework when it collects data about people and shares it with other companies to track them across apps and websites. That is a conditional rule. A package name, a vendor category, or a marketing label cannot answer it by itself. You need to inspect the data flow in the app you are shipping. This matters in AI-built apps because generated screens can hide a growing dependency tree. A first build may start with product analytics, then gain attribution, ad measurement, a support widget, or a third-party login. Each addition can change what data leaves the app and who receives it. Treat the tracking decision as a release check, not a one-time choice made when the first screen is generated. ## Map the data flow, not just the dependency list Start with the app’s actual release build and inventory the packages and native modules it includes. For each one, record the data it can access, when it sends data, the recipient, and the stated purpose. Review the module’s setup and configuration, then compare those claims with the app’s own events and network behavior during a test session. Do not infer tracking from the presence of a vendor SDK. An SDK may support several products, and the app’s configuration determines which features run. Conversely, a team should not assume that a package is outside ATT just because the app uses only a small part of it. Verify the behavior of the version and configuration in the shipped build. Use questions that connect collection and sharing: ![A review checkpoint separates app data collection from cross-company, cross-app tracking paths.](https://cdn.otf-kit.dev/blog/ios-app-tracking-transparency-permission/inbody-data-flow-20261011a.png) - Does the app collect data about a person or device? - Is that data sent to another company? - Is the data used to identify or follow the person across other companies’ apps or websites? - Does the app combine information from the app with information from other companies for that purpose? - Do any included modules make this happen even if the app’s own code does not? If the answer to Apple’s condition is yes, plan the ATT flow. If the answer is unclear, treat it as an unresolved release question: ask the SDK owner, inspect the configuration, and test the production-like build. Do not write a blanket statement that a particular analytics provider always does or never does tracking. ## Add the native permission flow deliberately Apple’s documentation identifies the AppTrackingTransparency framework and its ATTrackingManager authorization request. It also names NSUserTrackingUsageDescription, a message that explains why the app is requesting permission. When ATT applies, add the purpose string to the app target and request authorization at an appropriate point in the user experience. Plan the request around the feature that needs tracking. Explain the reason in the app before presenting the system request, using clear, accurate language. The purpose text should match the actual data use; it should not promise that data stays on the device if the app shares it, or suggest that permission is required to use unrelated app features if it is not. The authorization request is asynchronous. Keep the app usable while the system prompt is presented and handle the resulting status in the completion handler. Check the current authorization status when deciding whether to run the tracking-dependent path. Keep non-tracking functionality independent where possible, so a person’s choice does not break unrelated screens. For an app built with a JavaScript framework, the important release question is still the native iOS application that reaches the user. Confirm that the native project, configuration plugin, or build setup includes the required purpose string and authorization behavior in the binary. A JavaScript screen that mentions privacy does not substitute for the native ATT request when the rule applies. ![Testing both ATT outcomes keeps core app screens available while tracking-dependent behavior follows the authorization status.](https://cdn.otf-kit.dev/blog/ios-app-tracking-transparency-permission/inbody-consent-test-20261011a.png) ## Test the first-run and returning-user paths Test the app from a clean install on a real iOS device or a representative test setup. Confirm that the explanation appears at the intended moment, that the system prompt follows it, and that both authorization outcomes leave the app in a valid state. Also test a returning installation where the status is already determined; the app should not depend on showing the prompt again to reach its normal entry point. Then test the tracking-related feature separately from the rest of the app. With authorization granted, verify that the intended flow works. With authorization denied or restricted, verify that the app does not start the tracking path and that ordinary app functions remain available. Check logs and test traffic for data that should not be sent in that state. Include these checks in the release checklist: - The release build’s dependency inventory has an owner and review date. - The team has documented which data each relevant module collects and where it goes. - The ATT decision is tied to the actual configured behavior, not a vendor name. - The purpose string explains the real use in language a person can understand. - Both consent outcomes have been tested in the production-like build. - A dependency or configuration change triggers another review before release. ## Recheck when the app changes ATT review can become stale. A new attribution integration, a new ad campaign, an SDK configuration change, or a change in how events are joined with other data can alter the answer. Put the check in the same release process that reviews permissions, privacy disclosures, and production configuration. For teams generating apps from prompts, keep the decision visible in the project handoff. Record the feature, the data flow, the responsible module, the permission behavior, and the tests that support the decision. If the app changes from first-party measurement to cross-company tracking, revisit the ATT requirement before the build goes out. Do not use a successful build as proof that the privacy flow is correct. A binary can compile while the app’s data flow, purpose string, or authorization handling is incomplete. The useful release evidence is a reviewed dependency map and a tested user journey. ## How this fits with app privacy labels ATT and App Store privacy disclosures answer related but different implementation questions. This article focuses on whether the app must request tracking authorization for a particular data flow. For the separate work of documenting collected data in the store listing, see our guide to [app privacy labels for AI-built apps](/blog/app-privacy-labels-ai-built-app). Keep both checks tied to the same inventory so the app behavior and its disclosures do not drift apart. ## Sources - [App Tracking Transparency — Apple Developer Documentation](https://developer.apple.com/documentation/apptrackingtransparency) — definition of when ATT is needed, the framework, the purpose string, authorization request, and status.