Before you ship an SDK upgrade in a shopping app, confirm the new version is signed by the same developer, read its privacy manifest, diff what it collects, and test checkout and login. Apple's guidance is blunt: when you use an SDK, you are responsible for all the code it includes.
What Apple says
Apple's third-party SDK requirements page states that third-party SDKs can provide great functionality but can also affect user privacy in ways that are not obvious to developers and users. It reminds developers that when they use a third-party SDK, they are responsible for all the code the SDK includes in their app and need to be aware of its data collection and use practices.
Apple introduced two mechanisms to help, announced at WWDC23, according to that page.
Privacy manifests describe the privacy practices of third-party code in a single standard format. When you prepare to distribute, Xcode combines the privacy manifests of all third-party SDKs in your app into one report, which helps you complete accurate privacy labels.
Signatures for SDKs. When you adopt a new version of a third-party SDK, Xcode validates that it was signed by the same developer. Apple says this improves the integrity of your software supply chain.
Apple also lists commonly used SDKs that must include a privacy manifest, and a signature when used as binary dependencies, when you submit new apps or updates that add one of them. Check that page for the current list, since it can change.
Why retail apps need extra care
Shopping apps usually embed several SDKs: analytics, crash reporting, push notifications, payments, maps, attribution and social login. They run inside the app with its permissions, next to saved addresses, order history and payment flows.
The upgrade checklist
| Step | What to do |
|---|---|
| 1. Read the release notes | Look for new permissions, new network calls or renamed data fields |
| 2. Confirm the signature | Let Xcode validate the signer; investigate any mismatch before shipping |
| 3. Read the privacy manifest | Compare to the previous version for new data types or purposes |
| 4. Diff the dependency tree | Check for new nested packages the SDK pulls in |
| 5. Update privacy labels | Use the combined report so store disclosures stay accurate |
| 6. Test key flows | Login, search, cart, checkout, push and deep links |
| 7. Stage the rollout | Release to a small share of users first and watch crashes and errors |
A signature mismatch is a stop sign. It may be a changed publisher account, but it may also be tampering. Contact the SDK vendor through an official channel to find out.
Keep a register of SDKs
For each SDK record the version, the owner, the data it collects, the permissions it needs and the date of the last review. When a new advisory appears, you can answer in minutes which apps include the affected version.
Remove what you no longer need
Retired attribution or A/B testing SDKs often stay in the project long after the campaign ends. Each one adds code, data collection and an update burden. Remove them as part of a regular prune, as in our post on a quarterly prune for your storefront.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a dependency change can be held for review before it merges.
Where Safeguard fits
Safeguard has an iOS app and its SBOM and dependency scanning covers the dependencies declared in your repositories, with policies and gates that can review a dependency change before merge. A free scan is at gold.safeguard.sh/scan.
Quick check
Does a valid signature prove an SDK is safe?
No. It shows the same developer signed it. You still review the privacy manifest, the changes and the behavior.
Do all SDKs need a privacy manifest?
Apple requires it for the SDKs on its published list. Check the current list, and ask other vendors for one anyway.
Sources
Last reviewed: 19 October 2026.
