The Third-Party in the Room: Auditing What Your App’s SDKs Actually Send

There’s a particular kind of quiet panic that comes from opening the network inspector on a “privacy-first” app and watching a stream of requests fly out to domains you don’t recognise. Nothing is necessarily wrong. But if your App Store privacy label or Google Play Data safety form says one thing and your SDKs are doing another, you’ve got a launch-readiness problem that won’t fix itself.

This is especially relevant in the UK, where “no tracking” has a specific meaning to users and a slightly different one to regulators. Apple’s App Tracking Transparency talks about cross-app tracking. The ICO talks about personal data, lawful basis and fairness. Your customers mostly just read the label. Your job is to make sure all three versions of the story line up before someone with a clipboard asks.

Why “no tracking” isn’t the same as “no collection”

It’s easy to treat “we don’t track you” as a blanket claim. In practice, an app can avoid cross-app advertising tracking and still collect device identifiers, diagnostics, coarse location, session data and crash logs. Those things may be legitimate and useful. They still need to be declared.

The gap usually appears because privacy labels are completed by humans reading documentation, while SDKs are added by developers solving a problem. An analytics library gets dropped in for funnel metrics. A push provider gets added for retention. A crash reporter gets bundled because nobody wants to debug blind. Each one is reasonable. Together, they can quietly contradict the neat sentence on your store page.

Start with a bill of materials, not the listing

Before you touch the App Store Connect form, build a proper inventory of what’s inside the app. Treat it like a ingredients list, not a compliance chore.

On Android, check your Gradle dependency tree and any manifest mergers. On iOS, look at Swift Package Manager, CocoaPods and any prebuilt frameworks. Don’t forget the things that arrive transitively — an ad SDK that pulls in an attribution provider, or a crash reporter that brings its own networking layer.

For each SDK, write down four Things: what it is for, who owns it, what data it can access, and whether it runs at first launch or only after consent. If you can’t answer the last one, that’s the first red flag.

Run the traffic test on a clean install

Documentation tells you what an SDK should do. A proxy tells you what it actually does. Set up a clean device or emulator, install a fresh build, and capture traffic through a tool such as Proxyman, Charles or mitmproxy. If certificate pinning gets in the way, that itself is worth knowing about.

Open the app, leave it idle, then exercise the main flows. Watch for requests that fire before any consent screen appears. Look at payloads where you can, and note the domains. You don’t need to reverse-engineer everything. You need to know whether the app is sending data before the user has had a chance to say yes.

This is also where you catch the “helpful” SDK that phones home on launch with an install event, a device model and a rough location. That may be fine. It may also be the exact thing your privacy label says doesn’t happen.

The usual suspects

Analytics and attribution SDKs are the classic offenders because their job is to measure. Firebase, Mixpanel, Amplitude and similar tools can collect device identifiers, session data and event properties. Ad and attribution SDKs — Meta, Adjust, AppsFlyer and friends — often collect advertising identifiers and IP addresses. Crash reporters collect diagnostics, which sounds harmless until you realise diagnostics can include device state and user paths.

Then there are the quieter ones: push notification providers, social login SDKs, customer support widgets, location or weather libraries, and even some keyboard or emoji extensions. None of them are inherently bad. But if they’re present, they need to be in the data map and reflected in the store forms.

Reconcile the store forms properly

Apple’s privacy labels and Google’s Data safety section ask similar questions in different ways. Both want to know what data is collected, whether it’s linked to the user, and whether it’s used for tracking. The mistake is treating them as a marketing exercise and answering from memory.

Work from your SDK inventory and traffic findings. If an analytics SDK collects device ID and you’re using it for product improvement, declare it. If an ad SDK is present but dormant until consent, say so internally and make sure the app actually behaves that way. “We don’t use it” is not the same as “it’s in the binary.”

Under UK GDPR, accuracy and accountability matter. A misleading label isn’t just a store-policy issue; it can become a consumer protection and regulatory issue if users are told one thing and the app does another. The ICO’s expectations around transparency and data protection by design are not exotic. They mostly come down to knowing what you process and being honest about it.

Fix the listing before someone else does

Once you’ve got the inventory and the traffic evidence, decide what to do. Sometimes the fix is as simple as updating the label. Sometimes it’s removing an SDK you don’t need. Sometimes it’s delaying a non-essential SDK until after consent, or switching off automatic collection at initialisation.

Write a short internal data map: SDK, purpose, data categories, lawful basis, retention, and where it’s declared. Keep it with the release checklist. If a buyer or regulator asks, you’ll have a coherent answer rather than a scramble through old tickets.

A release gate you can repeat

Make this a routine, not a one-off panic. Before every major release, re-run the dependency inventory, repeat the clean-install traffic test, and diff the findings against the store listing. Assign one person to sign off the privacy forms. If a new SDK appears, it goes through the same gate.

The label on the store page is a promise. The SDKs in the binary are what actually happens. Closing that gap is unglamorous work, but it’s the kind of launch readiness that keeps a UK app out of trouble — and keeps the “no tracking” claim from becoming an awkward conversation.