Remove an SDK in seven steps: find every use, decide the replacement, remove code and dependencies, clean configuration and permissions, update store declarations, ship in a staged release, then verify from the built artifact that it is gone. Deleting the import line is the first step, not the last.
Why removal goes wrong
Removal is rarely rehearsed. Teams add an SDK with a ticket and remove it with a hunch. Leftovers cause real problems: unused permissions stay in the manifest, privacy answers still mention data nobody collects, and background services keep running. Apple tells developers to keep their privacy answers accurate and up to date when practices change, and removal is a practice change.
The playbook
1. Inventory its reach. Search source for imports and calls. Check the dependency files, build scripts, plist or manifest entries, initialisation code in the app startup path, push or deep link handlers, and any remote configuration that references it. Include transitive libraries it pulled in.
2. Decide the replacement. Options: build the feature yourself, switch to another approved SDK, or retire the feature. Record the decision in the register so the owner can close the entry.
3. Remove code and dependencies. Delete usage, then the dependency declaration, then update the lock file. In CocoaPods or SwiftPM, resolve again. In Gradle, regenerate the lockfile. Read the lock diff to confirm the transitive libraries left too.
4. Clean configuration. Remove permissions only that SDK needed, entitlements, background modes, URL schemes, exported components, network security exceptions, and any keys or tokens issued for it. Revoke the vendor account credentials as well.
5. Update declarations. Revisit your store privacy answers. Apple's app privacy page says third-party partners include analytics tools, advertising networks and third-party SDKs, and that you must declare their data collection. If the SDK was the only source of a data type, the declaration should change in the same release cycle. Check any data safety form and the open source notices screen too.
6. Ship in stages. Use a staged rollout and watch crash rates and the feature the SDK supported. See the fast fix guide for release timing.
7. Verify from the artifact. Do not trust the source tree alone. Generate an SBOM or inspect the built app and confirm the SDK, its frameworks and its permissions are absent. Then update the register with the removal date.
Handle old app versions
Users on older versions still run the SDK. If it is being removed for a security reason, a forced or recommended update may be appropriate. Forced updates and minimum OS versions covers how to decide.
Server side loose ends
Stop sending data to the vendor, delete data you hold in the vendor account where your agreement allows, and remove allowlisted domains from network rules. Ask the privacy owner whether any notice to users needs to change. That last point is a question for your privacy or legal advisers, not something this post can settle.
Try it yourself
Click through it at your own pace, or open it full screen.
Scan the component list and imagine the before and after of a removal. The after view is your verification step.
Safeguard can produce an SBOM and run dependency scans on the built project, which gives you a way to confirm the SDK is gone. A free scan is at gold.safeguard.sh/scan.
Quick check
Is removing the import enough?
No. Dependencies, permissions, configuration, credentials and store declarations all need cleanup.
How do I prove the SDK is gone?
Inspect the built artifact or its SBOM, not only the source tree.
Sources
Last reviewed: 19 October 2026.
