Run a test build on a device or emulator through an intercepting proxy, use the app with and without the SDK enabled, and compare every host and payload with what the vendor documents and what you declared. Record the differences. Anything unexplained blocks approval until the vendor answers.
Why test instead of read
Documentation says what a vendor intends. Traffic shows what happens. Apple's page reminds developers that they are responsible for all the code an SDK includes and need to know its data collection and use practices. You can only know those practices by observing them, so a traffic test belongs in the high tier review described in our tier guide.
Setup
- Use a dedicated test build and a test account. Never real customer data.
- Put the device and a proxy on the same network. Configure the device to send HTTP and HTTPS traffic to the proxy.
- Install the proxy's test certificate on the device so you can see decrypted content. Only do this on devices you own and for apps you build.
- Make a baseline capture with the SDK disabled or absent.
- Make a second capture with the SDK enabled and the same user journey.
What to record
| Item | Question to answer |
|---|---|
| Hosts contacted | Do they match the vendor's documented domains? |
| Timing | Does traffic occur at launch, in the background, or only on feature use? |
| Identifiers sent | Advertising ID, device ID, install ID, account ID? |
| Payload fields | Anything beyond what the feature needs, such as location or contacts? |
| Consent behaviour | Does traffic stop when consent is declined? |
| Transport | Is everything encrypted, and does the SDK respect your pinning settings? |
Save the capture files with the SDK version in the filename, and attach them to the register entry.
Limits you should state
- Some apps and SDKs pin certificates, so the proxy cannot see content. Do not bypass pinning in production builds. Record that the content was opaque and ask the vendor for a data flow description instead.
- A test run covers the paths you exercised. A rarely used feature may send other data.
- Behaviour can change with remote configuration or a vendor update. Repeat the test on major upgrades.
Compare with declarations
Match the observed fields against your store privacy answers. Apple's app privacy page says you must identify all data you or your third-party partners collect, and that data collected for reasons other than analytics or advertising still needs to be declared. If traffic shows a data type you did not declare, fix the declaration or fix the integration.
Also check the Google Play data safety form requirements for SDKs if you ship on Android.
Make it repeatable
Write the test as a short script of user actions so a different person can repeat it on the next version. Keep the proxy rules and expected host list in the repo. When a new version contacts a new host, the diff against the expected list is your alert.
Safeguard's dependency scanning and policies address the code side, listing what an SDK brings and flagging known advisories, while traffic testing covers runtime behaviour.
Quick check
Can I just read the vendor's privacy page?
Read it, then test. The page tells you intent, and traffic tells you behaviour.
What if the SDK pins its own certificates?
Do not tamper with production builds. Ask the vendor for a data flow document and test what you can, such as hosts and timing.
Sources
Last reviewed: 19 October 2026.
