Yes. Apple's guidelines say you are responsible for everything in your app, including ad networks, analytics services and third-party SDKs. Google says you alone are responsible for your Data safety declarations, which cover SDK data, and that non-compliant apps can face enforcement such as blocked updates or removal.
What Apple says
Three parts of the App Review Guidelines matter for SDKs:
- The introduction says you are responsible for making sure everything in your app complies, including ad networks, analytics services and third-party SDKs, so you should review and choose them carefully.
- Guideline 5.1.1(i) asks you to confirm that any third party you share user data with, such as analytics tools, ad networks and SDKs, provides the same or equal protection of user data as stated in your privacy policy.
- Guideline 5.1.2 says you may not use, transmit or share personal data without permission, and that apps sharing user data without consent or otherwise not complying with data privacy laws may be removed from sale and may lead to removal from the Apple Developer Program.
Guideline 2.5.2 adds that apps should be self-contained in their bundles and may not download, install or execute code that introduces or changes features or functionality.
What Google says
Google's Data safety help page says disclosures include data collected through third-party libraries and SDKs, and that data sent off the device by an SDK counts as collection. It says you must also ensure third-party code in your app complies with Play policies. If a declaration is inaccurate, Google may require a fix, and non-compliant apps can face blocked updates or removal.
How an SDK causes the problem
| SDK behavior | Store risk |
|---|---|
| Sends user data you did not disclose | Inaccurate declaration or labels |
| Shares data without consent | Violation of data use rules |
| Loads feature-changing code at runtime | Conflict with the self-contained app rule |
| Requests permissions you cannot justify | Questions in review |
| Has no privacy manifest where one is expected | Submission problems on iOS |
How to reduce the risk
- Keep a current SDK inventory per release.
- Read each SDK's data documentation before each major update.
- Diff your declarations and labels against the last release.
- Test the app's network traffic with a proxy on a test device, and see what leaves the app.
- Remove SDKs that nobody uses. Dead code still ships.
- Make one person accountable for store declarations.
What the rules do not say
Neither store promises it will catch an SDK problem for you. Google's page says its review is not designed to verify accuracy. So passing review is not evidence of compliance.
For privacy practices around SDK consent, see mobile SDK privacy and consent.
Quick check
If an SDK vendor says it is compliant, am I covered?
No. Both stores place responsibility on you as the app publisher.
What is the cheapest control?
A per release SDK inventory with an owner. Most store problems start with an SDK nobody remembered.
Safeguard covers the inventory side through dependency and SBOM scanning and can enforce policies on what enters a build. It does not decide your legal compliance. A free scan is available.
Sources
Last reviewed: 19 October 2026.
