CocoaPods “sandbox is not in sync”: run pod install after lockfile changes
Run pod install after any Podfile or lockfile change and keep the lockfile in version control.
The installed Pods no longer match the resolved lockfile. Run pod install, and if it persists, check that your CocoaPods version matches the lockfile and that the lockfile is committed.
Try these fixes in order
Run pod install
In the project directory, run pod install and rebuild. This regenerates the sandbox from the current Podfile.lock and clears the error in the common case.
pod installMatch the CocoaPods version to the lockfile
Open the end of Podfile.lock and read the COCOAPODS version entry. If it differs from pod --version, install the matching CocoaPods release so the sandbox is generated by the expected version.
pod --versiontail -5 Podfile.lockKeep the Podfile and lockfile tracked
Make sure Podfile and Podfile.lock are both committed and that the team's handling of the Pods directory is consistent. CocoaPods recommends keeping both files under version control.
git status --short Podfile Podfile.lockBuild from the workspace
Reopen the .xcworkspace, not the .xcodeproj, and build again. The check-script build phase verifies the sandbox on every build, so a clean install followed by a build confirms the fix.
Interpret what you see
The error appears right after a git pull, checkout, or merge
What it suggests: The installed Pods sandbox was generated from an older Podfile.lock than the one now in the project directory.
Next check: Run pod install in the project directory, then rebuild.
pod install runs but the error persists
What it suggests: The CocoaPods version that generated the sandbox differs from the installed one, so the check script cannot reconcile them.
Next check: Run pod --version and compare it with the COCOAPODS entry at the end of Podfile.lock.
The error appears on fresh clones or other machines
What it suggests: If the Pods directory is git-ignored and Podfile.lock is not committed, each checkout can silently carry a mismatched sandbox.
Next check: Confirm Podfile.lock is tracked in git and that Pods handling is consistent across the team.
Why this happens
- The Podfile or Podfile.lock changed, for example after a git pull or branch switch, without running pod install afterwards.
- The Pods directory or Podfile.lock is not tracked consistently, so the checkout does not match the resolved dependencies.
Still not working?
Do not edit the generated Pods project or the lockfile by hand to silence this check. The sandbox check exists to guarantee the built pods match the resolved dependency graph; bypassing it produces builds against the wrong library versions.
Official sources
These steps are based on the linked documentation and general diagnostics. BugMedic has not independently tested every product and system configuration. Review commands before running them.