Facebook App Events IOS: Tracking ID Bug

Hey there, fellow Flutter developers! Let's dive into a peculiar issue we've stumbled upon concerning the Facebook App Events plugin on iOS. This bug, while seemingly minor, can have implications for how your app handles advertiser tracking, especially when it comes to user consent and privacy. We're talking about a situation where the collectId parameter, which dictates whether advertiser IDs are collected, defaults to true even when you've explicitly set setAdvertiserTracking(enabled: false). This might sound a bit counterintuitive, and as we'll explore, it deviates from Meta's recommended practices.

The Root of the Problem: handleSetAdvertiserTracking in Swift

So, what's actually going on under the hood? The issue surfaces when we examine the handleSetAdvertiserTracking method within the SwiftFacebookAppEventsPlugin.swift file. Here, the line Settings.shared.isAdvertiserIDCollectionEnabled = collectId is where the magic (or in this case, the bug) happens. The collectId variable, by default, is set to true. This means that even if you're trying to disable advertiser ID collection by passing enabled: false to setAdvertiserTracking, the isAdvertiserIDCollectionEnabled property on the Facebook SDK's settings is still being set to true. This effectively overrides your intention to disable tracking.

Why This Matters: Meta's Guidelines and User Consent

This behavior is particularly concerning when you consider Meta's own documentation on advertiser ID collection. They clearly state that isAdvertiserIDCollectionEnabled should only be set to true after obtaining user consent. The documentation emphasizes that in certain scenarios, you might want to delay the collection of the advertiser ID rather than disable it entirely. This delay is crucial for scenarios where you need to acquire explicit user consent or fulfill legal obligations. The quote from their documentation is quite telling:

"In some cases, you want to delay the collection of advertiser_id, such as to obtain User consent or fulfill legal obligations, instead of disabling it. In this case, set Settings.shared.isAdvertiserIDCollectionEnabled = true after the end-user provides consent."

(Source: https://developers.facebook.com/docs/app-events/getting-started-app-events-ios#disable-advertiser-id)

By having collectId default to true and being assigned directly to isAdvertiserIDCollectionEnabled even when tracking is disabled, the plugin is essentially ignoring the user's implicit or explicit choice to opt-out of tracking at that moment. This could lead to unintended data collection and potential privacy concerns if not addressed.

The Expected Behavior: Aligning with Intent

So, what would be the ideal scenario here? The expected behavior, as suggested by the current issue report, is that if the enabled parameter passed to setAdvertiserTracking is false, then Settings.shared.isAdvertiserIDCollectionEnabled should also be set to false. This would directly reflect the developer's intent to disable tracking. The only exception would be if the developer explicitly provides a different value for the collectID parameter themselves, overriding the default behavior. This approach ensures that the plugin respects the developer's configuration and adheres to privacy best practices.

It’s about ensuring that the value set for isAdvertiserIDCollectionEnabled accurately represents the intended state of advertiser tracking. If the developer calls setAdvertiserTracking(enabled: false), the SDK should reflect that false state. If they call setAdvertiserTracking(enabled: true) and also want to control the collectId behavior explicitly, they should have the option to do so. This makes the API more predictable and safer to use.

Reproducing the Issue: A Closer Look

While the original report mentions "No response" for the