Closed tiwoc closed 4 years ago
@tiwoc Thanks for the detailed report! We will take a look.
hey @tiwoc ! We've just released SDK 8.0.0-beta1 which fully removes IDFA collection, in favor of an opt-in approach whereby you pass the IDFA to the SDK (if desired). Please see the migration guide here for details.
Looks great, thank you!
This is a long one, so lets start with a summary:
Summary
Apple only allows to use the Advertising ID (IDFA) for ad targeting and attribution. We don't have a use for the identifier and don't want to jump through the hoops that Apple recently put up (see below). We therefore can't use the AdSupport framework, but there's no way to disable it when using the mParticle SDK without forking the SDK and removing the related code. We propose to add a couple of
#if defined
s to make sure the code accessing the IDFA doesn't make it into our app.Background
When submitting an iOS app to Apple's app review team to get it into the app store, developers have to explain their use of the Identifier for Advertising (IDFA). The prompt in App Store Connect looks like this if you state that you collect the ID:
Full questionnaire when selecting Yes in App Store Connect (click to expand)
(See also section 3.3.12 of the current version of the Apple Developer Program License Agreement, need to be signed in with a developer Apple ID to access this file.)
Since we don't use the IDFA at all, and since mParticle also collects the Identifier for Vendor (IDFV) which is more reliable for generating user IDs within a single app (users can't reset or disable it), we'd like to disable the code in the mParticle SDK that collects the IDFA so that we can answer No the the question about the IDFA.
Current status
We're using both the mParticle SDK and the Braze/AppBoy integration with mParticle. Both use the IDFA.
mParticle SDK
There's a preprocessor flag for disabling the import of the AdSupport framework here: https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK/Utils/MPDevice.m#L18-L20 This doesn't have any effect, though, because the actual client code doesn't reference the imported symbols at all but uses the Objective-C runtime to dynamically call into AdSupport: https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK/Utils/MPDevice.m#L120-L149
This code is called for every Identify request and seems to be sent to mParticle servers.
Suggested change to the mParticle SDK
We'd like to have the body of
-[MPDevice advertiserId]
surrounded with something likeWe can then use the
post_install
step in our Podfile to addMP_NO_IDFA
to the set of compiler definitions for compiling pods.At least the CocoaPods install will still link to AdSupport, but linking to but not using the framework should be fine (from personal experience), so I guess we don't need a change here. https://github.com/mParticle/mparticle-apple-sdk/blob/c3ed1ac6eab6305e9c1f4d968f5be36ebe99741d/mParticle-Apple-SDK.podspec#L52
Braze/AppBoy integration with mParticle
In the mparticle-apple-integration-appboy repo, there are two methods that access the IDFA in a similar way to the main SDK: MPKitAppboy.m#L186-L229 (sorry, inline diffs across repos or orgs don't seem to work in GitHub).
At first look, it seems like setting
collectIDFA
to false would disable IDFA collection, but that isn't the case: The Braze/AppBoy SDK doesn't checkisAdvertisingTrackingEnabled
before accessingadvertisingIdentifierString
, wherecollectIDFA
isn't checked. Also, this would still leave the "forbidden" code in the app.Suggested change to the Braze/AppBoy integration with mParticle
Similar to the change to the base SDK, we'd like to guard the bodies of these two methods with
#if defined(MP_NO_IDFA)
and returnfalse
/nil
ifMP_NO_IDFA
is defined.