The 'could not resolve package dependencies' error stops Xcode builds cold. This focused fix guide covers the most common causes, from network and authentication issues to stale caches, with concrete steps to get resolving again.
When Xcode reports that it could not resolve package dependencies, it is telling you that SPM was unable to compute a valid, downloadable set of versions for your declared dependencies.
Resolution is the step where SPM reads your manifest and Package.resolved, contacts each dependency's Git repository, and figures out which versions satisfy every constraint at once.
If any part of that process fails, whether a repository is unreachable, a version rule cannot be satisfied, or a cache is corrupt, the whole resolution stops.
The error message itself is often generic, which is why it feels frustrating. The real cause is usually one of a handful of common issues.
This guide walks through those causes in order, from the quickest checks to the more involved fixes, so you can restore a working build methodically.
Because resolution downloads code over the network, connectivity problems are the single most common cause. Start here before anything else.
Confirm you have a working internet connection and that you are not behind a restrictive proxy or firewall that blocks Git traffic. Corporate networks sometimes block the ports Git uses.
Next, verify the repository URL in your manifest is correct and still exists. Open it in a browser. A renamed, moved, or deleted repository will fail to resolve.
If the package is private, confirm your access has not lapsed. A revoked token or removed collaborator permission produces resolution failures that look like network errors.
Once you have confirmed the repository is reachable and the URL is right, retry resolution with File then Packages then Resolve Package Versions before moving on.
Private dependencies fail to resolve when Xcode cannot authenticate to the hosting service. This is a frequent and easily fixed cause.
Open Xcode Settings and go to the Accounts tab. Confirm your GitHub or other source-control account is present and its credentials are still valid.
If you use a personal access token, verify the token has not expired and still grants read access to the repository. Regenerate and re-add it if needed.
For SSH-based access, confirm your SSH key is added to your account and loaded in your local agent. The URL scheme in your manifest, HTTPS versus SSH, must match the credentials you have configured.
After fixing authentication, resolve packages again. Correct credentials often clear an error that otherwise looks mysterious.
SPM caches downloaded packages to speed up builds, but a stale or corrupt cache can block resolution even when everything else is correct.
In Xcode, choose File then Packages then Reset Package Caches. This clears the cached package data and forces SPM to fetch fresh copies.
Follow that with File then Packages then Resolve Package Versions to trigger a clean resolution.
If the problem persists, you can go further by deleting Xcode's derived data for the project, which removes intermediate build state that sometimes holds onto bad package information.
Resetting caches resolves a surprising share of mysterious failures, so it is worth doing early whenever the URL and credentials are confirmed correct. Give resolution a moment to complete after the reset before judging whether it worked.
The Package.resolved file pins exact versions, and occasionally it becomes inconsistent with your manifest, blocking resolution.
This can happen after a messy merge, when two teammates resolved different versions and the conflict was resolved incorrectly in Git.
Open Package.resolved and check for merge conflict markers or obviously wrong entries. If it looks corrupted, you can delete it and let SPM regenerate a fresh one.
After deleting, run File then Packages then Resolve Package Versions. SPM will recompute versions from your manifest and write a new Package.resolved.
Review the regenerated file, run your tests to confirm the chosen versions behave, and then commit it. Keeping Package.resolved clean and conflict-free in source control prevents this class of failure from recurring across your team.
Sometimes resolution genuinely cannot succeed because your constraints contradict each other. This is a logical failure rather than an environmental one.
For example, two dependencies might each require incompatible versions of a shared third dependency. No single version satisfies both, so SPM gives up.
Read the error text carefully; SPM often names the packages and version ranges involved, even if the wording is dense. Those names point directly at the conflict.
Try loosening an overly strict rule, such as changing an exact pin to 'up to next major,' or updating one dependency to a newer release that relaxes its own requirements.
We cover deep version-conflict debugging in a dedicated guide, but for a generic resolution failure, confirming that your rules are mutually satisfiable is an essential check.
If individual fixes have not worked, a full clean-state rebuild clears out any lingering corruption.
Quit and reopen Xcode to release any locked state. Then reset package caches, delete derived data, and if necessary remove the local SPM cache directory in your home Library folder.
Clean the build folder with Shift plus Command plus K, then resolve packages and build again from scratch.
For teams, try cloning the repository fresh into a new folder and resolving there. If a clean clone resolves successfully, the problem lives in your working copy rather than in the project configuration.
This nuclear option is rarely needed, but when a machine's package state is truly wedged, starting from a clean slate is faster than chasing every possible cause individually.
A few habits keep resolution failures rare. First, always commit Package.resolved and resolve merge conflicts in it deliberately rather than blindly accepting one side.
Second, prefer sensible version rules like 'up to next major' over exact pins where possible, which gives SPM room to find a compatible set.
Third, keep your Xcode and toolchain reasonably current, since older versions occasionally struggle with newer package formats.
Fourth, document any private-repository access requirements for your team so new members configure credentials before their first build.
Finally, remember that SPM only manages dependencies; it does not replace Xcode or the Apple Developer Program for shipping. Keeping resolution healthy simply keeps your native build unblocked, so the rest of your development and release workflow can proceed without interruption.
Choose File then Packages then Reset Package Caches, then File then Packages then Resolve Package Versions. This clears cached data and forces a fresh fetch.
Yes. A merge-conflicted or corrupted Package.resolved can block resolution. You can delete it and let SPM regenerate a clean one, then commit the result.
Usually authentication. Check that your source-control account and token or SSH key in Xcode Settings are valid and still grant read access to the repository.
That is a genuine constraint conflict. Loosen a strict version rule or update a dependency to a version that relaxes its requirements so a compatible set exists.
Indirectly, because you cannot build until it is resolved. SPM manages dependencies only; shipping still requires Xcode and the Apple Developer Program.