This story has moved a lot since it was published – our update from March 3 tells the latest.

Apple announced last summer that they will soon require users to opt in before apps can get the infamous “IDFA” tracking identifier for that user. While this was controversial in the ad tech sphere, most mobile apps can get by without this identifier.

However, most mobile app teams do collect analytics to help make product decisions. What features inspire free users to convert to paid users? Why do we think our trial is converting poorly? Do we still need to support iOS 12? A lot of apps use free SDKs to collect and analyze this kind of data.

The most popular analytics SDKs are free because they’re owned by companies that sell ads, or share data with those companies: Google Analytics, Flurry, and Google’s Firebase. Paid competitors like Mixpanel and Amplitude can be really powerful, but often cost thousands of dollars a year or more.

Now, I can’t find this said explicitly anywhere. But it seems like, along with the incoming restrictions on IDFA and ad attribution, Apple is also enacting a de-facto ban on these free analytics SDKs. The setup looks like this:

1. Since December, App Store Connect’s App Privacy submission process has required developers to indicate if they have “3rd Party Tracking”. Developers are told to do this if they’re including an SDK from a company that hosts ads or shares data with advertisers across apps.
2. In the coming weeks, iOS 14.5 will require apps that engage in “3rd Party Tracking” to ask explicit permission, which most users will opt out of.
3. App Review will soon start rejecting apps that are not following the opt in provisions. They’ll likely do this by comparing the app’s App Privacy metadata to the use of the new opt-in APIs, as well as scanning apps for the presence of certain SDKs.
4. Therefore, it seems, iOS apps currently using the Google Analytics, Flurry, and Firebase SDKs may need to migrate off of them promptly and instead use an analytics tool not owned by a company that displays ads. Popular choices include Mixpanel, Amplitude, or a self-managed analytics tool.

These new rules could be a big hurdle for some developers, especially if they currently rely on other SDKs that do 3rd party tracking or attribution, such as Facebook’s.

Do we really have to?

The challenging thing for developers evaluating all this is that many of the points above have not been said so explicitly by Apple. Apple has instead outlined a series of rules, each rule being worded somewhat differently between the App Privacy documentation and the App Tracking Transparency documentation. A generous reading makes it seem like you maybe could comply with the rules and still use some of these SDKs. Maybe.

Apple did not – and from a legal perspective likely can’t – explicitly ban the Google Analytics, Flurry, Facebook, and Firebase SDKs. Their wording leaves some wiggle room. It seems like it could be possible to use them. It seems even more possible that Facebook and Google could make them usable. However, this puts developers in the situation of evaluating the changing documentation, complex privacy policies, and large settings panels that these tools offer, trying to judge whether a given setup of a given SDK would now pass muster from Apple’s perspective.

For example, in App Store Connect – where developers indicate if they have Third Party Tracking – Apple asks if your app is:

Sharing data with entities who display third-party ads.

It seems maybe impossible for a Google-owned analytics SDK to not trigger this provision. In contrast, the AppTrackingTransparency documentation asks whether you are:

Placing a third-party SDK in your app that combines user data from your app with user data from other developers’ apps to target advertising or measure advertising efficiency.

Does it matter if the SDK combines user data in general, or is it sufficient if you’ve been assured that your app’s user data in particular won’t be combined by the SDK? The logical complexities and differences in wording raise questions that, unfortunately, developers need to make assumptions about until we hear something from Apple, or we hear through the grapevine how App Review actually enforces these rules. In particular we need to make three guesses:

1. Will you be allowed to indicate your app has 3rd Party Tracking, not implement the opt-in dialog, but still get App Review to approve you as long as you believe you’re not required to do opt-in based on your evaluation of the SDK, its settings, and the exact wording in the AppTrackingTransparency documentation? Our guess is no. It seems likely that Apple will expect that all 3rd Party Tracking requires the opt-in dialog.
2. Will you be allowed to include an SDK that App Review considers a “3rd Party Tracking SDK”, but not indicate 3rd Party Tracking in your App Privacy data as long as you believe you’re not required to based on your evaluation of the SDK, its settings, and the exact wording of the App Privacy documentation? Our guess is no. It seems like Apple will probably consider any use of the Facebook and Google SDKs to be 3rd Party Tracking.
3. Is it safe to continue using – or migrate to – 3rd party product analytics tools like MixPanel and Amplitude that are not owned by advertising companies? Our guess is yes. These rules seem squarely aimed at companies involved in advertising.

If one of the above assumptions is wrong – for example, maybe these SDKs can be configured to behave sufficiently privately, and App Review can be convinced that this has been done for your app – then that would be really useful to know. If anybody has more information on what Apple will or won’t be allowing, or even conflicting hunches, let me know.

Does our SDK require App Tracking Transparency? Uh… well…

Firebase, Google Analytics, and Facebook have been releasing updates and documentation to help developers navigate Apple’s questions, but conspiciously they don’t directly answer them. Instead they answer different, related questions that are maybe helpful but are certainly not decisive.

Contrast that to paid analytics tools that don’t share data with ad companies. MixPanel, for example, posted clearly 6 months ago that they believe they’re compliant with Apple’s rules:

You need to specify what data is used to track someone across external apps and websites, which in our case is none. We only allow customers to track data they own; data sent to Mixpanel is not used by any other external companies.

Interestingly, Flurry – whose business model apparently is to share data with advertisers – has also claimed its SDK doesn’t trigger the App Tracking Transparency rules. This seems dubious, but is interesting if so.

However, if the above rules and assumptions are correct, any apps that don’t both purge these SDKs and set their App Privacy to say they no longer have 3rd Party Tracking – or only use the SDKs for the small percentage of users who opt in – will soon face rejection. Meanwhile, even besides these restrictions, there are some substantial benefits to using premium analytics services like Mixpanel.

Our advice for now, then, is that all iOS apps should be prepared to migrate off of the Google Analytics, Firebase, Facebook, and Flurry SDKs, potentially on very short notice. If you were already on the fence, now is probably a good time to make the move. A lot of apps might be making changes in the coming weeks.

Hold on to your butts.

Updates, February 11 through March 3

A number of developers have gotten in touch to share their guesses about how App Review will handle this in the coming weeks – thanks folks! Some common themes:

1. Many developers assume Apple will only be using App Review to enforce opt-in for the IDFA identifier, and will not start rejecting apps for using SDKs that go against their new rules prohibiting things like combining data and using fingerprinting, as long as developers assert their SDKs are following the rules. This is plausible. If Apple goes this route though, developers are left with the ongoing risk of a surprise rejection, when App Review later cracks down on a specific SDK that’s played loose with the rules.
2. Flurry posted back in July 2020 that it intends to comply with Apple’s requirements so as not to require opt-in. In particular, they’ve explicitly said “Flurry will respect Apple’s policy requirement to not combine data across apps and websites owned by other companies.” It’s not clear how Apple would verify this is true, and this is surprising given Flurry’s business model, but it seems like a clear statement that Flurry intends to comply.
3. A couple folks has asked if embedding code from YouTube – which certainly does ad targeting with its data – would violate Apple’s privacy rules. By the letter of the policy, this seems possible.
4. Google has now joined Flurry in publicly disavowing tracking, which shifts the narrative towards these SDKs probably being allowed come iOS 14.5. Still, the wording of Apple’s App Privacy labelling UI makes this somewhat unclear.