Meta SDK and Apple ATT: review tracking and App Events
When your iOS app uses a Meta SDK, review App Events, advertising identifiers, consent state, and cross-app or cross-company use in the production flow before deciding how Apple App Tracking Transparency applies to your app.
What Meta SDK implies for your Apple App Store answers
Meta Platform SDKs may support login, analytics, and advertising measurement. Exact data use depends on which SDK products and events you enable.
| App Fact | Apple App Store | Google Play | Collection |
|---|---|---|---|
| Advertising identifier | Device ID (advertising identifier)Identifiers | Advertising IDDevice or other IDs | Depends on config |
| Device ID | Device IDIdentifiers | Device or other IDsDevice or other IDs | Depends on config |
| Product interaction | Product InteractionUsage Data | App interactionsApp activity | Depends on config |
- Advertising identifier and Device ID
Advertising identifiers may be used depending on configuration and platform rules
If used for advertising measurement; tracking needs confirmation.
You confirm: Used for advertising · Tracks users across other apps/websites
- Product interaction
If App Events are enabled.
You confirm: Feature usage measured
What this profile does not cover
- Meta Platform covers multiple products — confirm Login vs App Events vs advertising use cases separately.
Identify the Meta products in your build
Meta SDK integrations can cover different jobs, including Login, App Events, and advertising measurement. Do not treat the umbrella name as a single data flow. Start with the release target, list the Meta packages and initialization calls, and identify which products are enabled in the configuration used for submission.
Then trace the data that leaves the device. Record whether your app sends App Events, device or advertising identifiers, account-related values, campaign information, or custom event parameters. Include data sent before login, after login, and after a user changes consent. A development build with test settings is not enough evidence for the production decision.
Check whether another wrapper or marketing tool calls the Meta SDK on your behalf. Review deep links, attribution integrations, ad mediation, and server-side event forwarding. A code search for one SDK method can miss a dependency that initializes the same capability through a different package.
Understand what ATT is asking
Apple's App Tracking Transparency framework focuses on tracking across apps or websites owned by other companies. The presence of Meta Login, an App Event, or a device identifier does not answer that question by itself. You must review the purpose, linkage, and destination of the data in your actual integration.
Ask what happens to an identifier after collection. Is it used only to operate your app, measure events inside your own service, prevent fraud, or understand product use? Is it combined with data from other companies' apps or websites for advertising or measurement? Do a partner or server receive the value for that cross-company purpose? Keep those cases separate.
If the answer depends on a campaign, audience, partner, or environment, inspect the production settings for each supported configuration. Do not assume that a consent prompt shown by one tool covers every data path. Document which control gates Meta collection and which control gates cross-app use.
Review the App Facts carefully
The Meta SDK profile suggests analytics and advertising purposes as possible, App Events as configuration-dependent, and advertising identifiers as configuration-dependent. These are App Facts for review. The catalog suggests them with reasons and confidence; the developer confirms them after checking code, settings, payloads, and consent behavior.
Use the App Passport to keep each question attached to evidence. Confirm whether App Events are enabled, what fields they contain, and whether they are sent for users who have not signed in. Confirm whether an advertising identifier is collected or used, and whether a user can access the core app when consent is refused. If your app uses Meta Login without App Events or advertising measurement, keep the authentication path distinct from the tracking analysis.
An App Fact that is awaiting confirmation should stay that way until someone with knowledge of the release has reviewed it. Do not convert a likely or possible suggestion into a final store answer just because the SDK is present. The purpose of the review is to describe your app's behavior, not to fill every field from a vendor's product name.
Plan the ATT experience
If your integration involves tracking under Apple's definition, make the ATT request understandable and place it in a flow where the user can make a meaningful choice. Explain the purpose in the system prompt configuration and do not imply that accepting the prompt is required for unrelated app features unless your actual product behavior makes that necessary.
Test the denied, restricted, and not-determined states. Confirm which SDK calls run before the prompt, what data is sent after denial, and how the app behaves if the user later changes the setting. If a consent management platform is also present, map its state to the SDK's behavior instead of assuming the two settings stay synchronized automatically.
Review reinstall, upgrade, child-account, and region-specific paths when they change the prompt or data flow. Keep a record of which build and configuration you tested. ATT decisions are tied to implementation and purpose, so a later change to event forwarding or advertising partners can require a fresh review.
Keep every surface consistent
Use Safe Mode while the Meta products, payloads, or cross-app purpose are still being confirmed. It keeps uncertainty visible in the App Passport rather than encouraging a confident answer built on an incomplete inventory. When the flow is ready, compare the App Facts with the privacy copy, consent screens, SDK settings, and store submission details.
Run Consistency Check after changing the ATT prompt, partner setup, event schema, or initialization order. Check that your Public Pages, if they describe tracking or consent, use the same terms as the app. Check that your App Passport records the current release rather than an old integration. Consistency does not replace your technical review; it helps expose contradictions between the surfaces you control.
Declora is not a law firm, and it cannot guarantee store approval. It provides a structured review of App Facts and configuration questions, while you remain responsible for confirming your tracking analysis and submitting accurate information.
Common mistakes
One mistake is equating Meta Login with cross-app tracking. Another is assuming that a device identifier is harmless because it is not an email address. A third is asking for ATT permission after the SDK has already sent data, without checking what the production initialization path does before the prompt.
Avoid using a generic consent statement for distinct purposes. Analytics inside your app, advertising measurement, and cross-company targeting may involve different data flows. Record the purpose and destination for each, test the controls, and revisit the review whenever a partner or event pipeline changes.
FAQ
Does adding Meta Login automatically require an ATT prompt?
No. Login and tracking are different questions. Review whether your app links data across apps or websites owned by other companies for advertising or measurement. The SDK's presence alone does not settle the ATT analysis.
Do App Events count as tracking?
An App Event is a data signal, not a complete tracking classification. Review what the event contains, where it goes, how it is combined with other data, and whether the purpose involves cross-app or cross-company tracking. Confirm the App Fact from the production integration.
What should happen when a user denies ATT?
Your app should follow the behavior you have designed and documented for denial. Test which Meta calls remain active, what identifiers are available, whether events are suppressed or limited, and whether any server-side path continues to send related data.
When should I rerun the review?
Rerun it after adding App Events, changing event parameters, enabling advertising measurement, changing partner settings, moving SDK initialization, or updating consent controls. Then update the App Facts and run Consistency Check against the release build.
Sources
- App privacy details on the App Store — Apple, checked 2026-07-22
- App Tracking Transparency — Apple, checked 2026-07-22
- Meta Platform Terms (data use for Platform / SDKs) — Meta, checked 2026-07-22
- Google Play Ads policy — Google, checked 2026-07-22
- Provide information for Google Play's Data safety section — Google, checked 2026-07-22
- Guide updated
- 2026-09-19
- Profile last reviewed
- 2026-07-22
- Catalog version
- 2026.07.2 · profile 1.0.0
Related guides
- AppsFlyer and Apple ATT: review attribution and trackingApple App Store · Tracking & ATT
- Does Google Sign-In count as tracking under Apple's App Tracking Transparency?Apple App Store · Tracking & ATT
- Supabase and Apple Public Pages: privacy policy and support detailsApple App Store · Public Pages
- Cloudinary and Apple Public Pages: publish a clear privacy pathApple App Store · Public Pages