Do not review only the version number. Compare the merged manifest or plist, the resolved dependency tree, the build settings, the network behaviour and the SDK changelog. A one line bump can add permissions, new transitive packages and a higher platform minimum.
Why the diff is small and the change is large
A pull request that edits one version string looks harmless. The real change sits in the SDK's own release: new code, new dependencies of its own, new declarations in its manifest. None of that shows in your diff unless you generate it.
Seven things to compare
- Merged manifest or Info.plist. On Android, build the release variant and diff the merged manifest against the previous release. Look for new permissions, exported components, services and receivers. On iOS, diff the entitlements and plist keys.
- Resolved dependency tree. Diff the output of your dependency report or lockfile. New transitive packages are new code in your app. See how to read a lockfile diff.
- Platform minimums. Check minSdk, compileSdk and the deployment target. See what an SDK upgrade can force on Android and the Xcode and iOS minimum question.
- Privacy declarations. Check whether the SDK's privacy manifest or data safety information changed, because your own store declarations may need an update.
- Network behaviour. Run the app against a proxy in a test environment and compare the hosts the SDK contacts. Our post on testing what a mobile SDK sends over the network shows how.
- Binary size and startup time. A new release can add megabytes or slow launch. Measure both on a mid range device.
- Changelog and advisories. Read every entry between your version and the target, not only the latest. Look for removed methods, renamed options and security fixes.
Make the checks automatic where you can
| Check | Can be automated? | How |
|---|---|---|
| Manifest diff | Yes | CI job that builds, extracts and diffs merged manifest |
| Dependency diff | Yes | Compare resolved report or lockfile |
| Policy on new packages | Yes | Pull request gate |
| Network diff | Partly | Scripted run of key flows through a proxy |
| Changelog read | No | Reviewer, with a checklist |
A pull request gate that fails when a new permission or an unapproved package appears is the cheapest control. It turns the review from a hope into a rule.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a pull request is blocked when it introduces something the policy does not allow.
What a reviewer should record
Write three lines in the pull request: what changed in the merged manifest, what changed in the dependency tree, and which changelog entries mattered. A future reader, or an auditor, then sees that the upgrade was examined and not just accepted.
Where Safeguard fits
Safeguard's policies, gates and guardrails can check pull requests that change dependencies, and its dependency scanning and SBOM output give the before and after inventory. A free scan is at gold.safeguard.sh/scan.
Quick check
Why diff the merged manifest and not the source manifest?
Libraries add their own entries during the build merge. Only the merged result shows what the shipped app declares.
Is reading only the latest changelog entry enough?
No. If you skip several versions, changes from each one apply to you.
Last reviewed: 19 October 2026.
