Third-party SDKs and trackers: your app, your responsibility
A mobile app commonly ships with dozens of third-party SDKs: ad networks, attribution, analytics, crash reporting, payments. Each one runs its own code inside your app, with your permissions, towards its own servers. And everything they do there binds you.
A responsibility you cannot delegate
The CNIL’s position is consistent: the publisher bears at minimum joint controllership for trackers used by any SDK embedded in the app, and must audit whether partners honor their commitments.
A contract with the SDK provider is not enough. You need to know what the SDK actually does inside the app, not just what its documentation promises.
The Grindr precedent
The Grindr case illustrates the risk. Norway’s authority imposed a fine of 65 million kroner, around 6 million euros, for user data shared with advertising partners through the SDKs embedded in the app, without valid consent. The decision was upheld on appeal in October 2025.
The fine targets the app’s publisher. Not the ad networks that received the data.
Inventory first
The starting point is an honest inventory: which SDKs are actually present in the distributed binary, beyond what teams believe they integrated. Transitive dependencies and inherited versions hold surprises.
Public databases list several hundred known trackers, identifiable through code and network signatures. That is the baseline an app should be screened against, on every release.
Then the evidence
The inventory says what is embedded, not what happens. What remains is observing actual behavior: which data leaves before consent, what happens after a refusal, towards which domains, in which countries.
That dated, reproducible evidence is what makes the difference during an inspection. A publisher who can answer these questions before the regulator stays in control of the timeline.