How do you block unapproved SDKs in mobile CI with an allowlist?

Export the resolved dependency list from your lock files, compare it with an approved register file in the repo, and fail the pull request when something unlisted appears. Keep the check small, make the failure message say how to request approval, and give owners a way to grant time limited exceptions.

Why a CI check

An approval workflow only works if skipping it is harder than following it. Developers add dependencies under deadline pressure, and transitive libraries arrive without anyone choosing them. CI sees every change, so it is the right place for the enforcement point.

What to compare

Use the lock files, not the declared dependencies, because they list what resolved:

• Gradle: gradle.lockfile, produced by dependency locking. See locking Android versions.
• CocoaPods: Podfile.lock, which tracks the version of each Pod installed.
• Swift Package Manager: Package.resolved.

See pinning iOS versions for how those files behave.

Steps

1. Create an approved list in the repo, one entry per line: coordinate or name, approved version range, owner, review date, expiry for exceptions.
2. Write a short script that reads each lock file and prints names and versions.
3. Compare the output with the approved list. Report three classes: unknown component, known component with a version outside the approved range, and expired exception.
4. Fail the job on unknown components. Warn on version outside range, and fail it for high tier SDKs.
5. In the failure message, link to the request form and name the approver group.
6. Require the approver group on any pull request that edits the approved list. Use code owners so this is enforced, not merely agreed.
7. Run the same check on a nightly schedule against the main branch, so drift introduced some other way still surfaces.

Handle transitive dependencies

An approved SDK may add ten transitive libraries. Do not make people approve each one by hand. Approve the parent and allow its transitive set at the approved version, then fail only when the transitive set changes in a way the diff shows: new group, new network capable library, or a changed licence. This keeps noise manageable.

Exceptions

Sometimes a release cannot wait. Allow an exception entry with an expiry date and an owner. The nightly run fails when the expiry passes. Without that date, exceptions become permanent. See exception handling.

Try it yourself

Click through it at your own pace, or open it full screen.

Watch what a failing gate tells the developer and what they can do next. A good gate explains itself.

Safeguard supports policies, gates and guardrails on pull requests, along with dependency scanning, so this kind of check can be run from policy rather than a hand written script. A free scan is at gold.safeguard.sh/scan.

Quick check

Sources

• Gradle: Locking dependency versions
• CocoaPods guide: Using CocoaPods
• Swift Package Manager: PackageDescription

Last reviewed: 19 October 2026.