Xcode and Swift Package Manager dependency resolution and DerivedData invalidation

Answer

Xcode reuses an existing Package.resolved when the file is present and the resolved pins still satisfy the current Package.swift constraints. Re-resolution is triggered when Package.resolved is missing, does not satisfy the constraints, or a dependency-related edit to Package.swift makes the existing pins invalid. A change to Package.swift does not always invalidate DerivedData for the affected packages; only changes that affect the resolved version graph cause a full re-resolve and removal of compiled intermediates for those packages. For low-frequency releases, commit Package.resolved and update it deliberately on a release cadence.

Confirmed facts

• Xcode reads Package.resolved if present. If the pins match the current Package.swift version requirements, Xcode reuses them and does not invoke the resolver.
• Re-resolution occurs when Package.resolved is missing, outdated, or when Package.swift changes version requirements, adds or removes a dependency, or changes a dependency’s requirement in a way that invalidates the existing pins. Xcode then runs SPM resolution and writes a new Package.resolved.
• Manual re-resolution is forced via File > Packages > Reset Package Caches, or by deleting Package.resolved.
• Xcode Cloud performs a fresh resolution unless Package.resolved is committed and a dependency cache is configured; local Xcode respects the committed file by default.

Likely explanation, not confirmed across all Xcode versions

• Edits to Package.swift that do not affect dependency constraints, e.g., product names, target settings, Swift tools version metadata, may reuse Package.resolved. DerivedData invalidation in that case is typically limited to the changed targets, not a full package rebuild.
• DerivedData invalidation is not guaranteed for every Package.swift edit. Only changes that affect the resolved version graph trigger removal of the compiled intermediates for those packages under DerivedData/Build/Intermediates.noindex. Behavior is version-sensitive, particularly pre-Xcode 12.5 where Package.resolved handling was less strict.

Practical steps for reproducible, low-frequency releases

1. Commit Package.resolved to source control. This makes local and CI builds reproducible.
2. Use explicit, narrow version requirements in Package.swift for release branches, e.g., exact versions or tight ranges, to avoid accidental drift.
3. Schedule dependency updates intentionally: run swift package update or change a requirement in Package.swift, let Xcode re-resolve, verify, then commit the new Package.resolved.
4. Avoid manual cache resets in day-to-day work. Use reset only to recover from corrupted caches.
5. For Xcode Cloud, keep Package.resolved committed and configure a dependency cache if you want to avoid network resolution on every build.

Uncertainty note: exact DerivedData invalidation granularity varies by Xcode version and project structure. Verification is recommended by changing a dependency version and observing Package.resolved update and DerivedData cleanup for that package, then making a non-dependency edit and confirming Package.resolved remains unchanged.

One diagnostic detail that would change the recommendation: the Xcode version in use. Behavior of Package.resolved reuse and DerivedData invalidation is version-sensitive, and guidance for Xcode Cloud caching depends on the Xcode Cloud runtime version.