Xcode ↔ Swift Package Manager: Conflict Resolution for Shared Dependencies

Question

Xcode ↔ Swift Package Manager: Conflict Resolution for Shared Dependencies
In a workspace that imports two Swift packages, each declaring a dependency on a different major version of the same third‑party library, Xcode’s resolver consistently selects the highest available version. This behavior is not documented in the public Xcode or Swift Package Manager guides, and it can lead to binary incompatibilities that only surface at runtime.
Before attempting any optimization, a developer would like to quantify how much time the resolver consumes during the build. The Instruments Build Time template isolates the dependency‑resolution phase, but the exact contribution of network latency versus algorithmic complexity remains unclear.
Given this uncertainty, the following questions need clarification:

What criteria does Xcode use to pick a version when two packages request different major versions of the same dependency?
Can the selection be overridden or influenced via Xcode settings or the Package.swift manifest?
What is the most reliable way to isolate and measure the resolver’s runtime with Instruments before applying any performance tweaks?

Tasadduq Burney · Answer

Xcode ↔ Swift Package Manager: Conflict Resolution for Shared Dependencies
Likely explanation
When several packages in a workspace declare different version ranges for the same library, the SPM resolver first tries to find a version that satisfies all constraints. If more than one version meets those constraints, the resolver prefers the newest (highest) version that does so. This “pick‑the‑latest‑satisfying” rule is not advertised in the official guides but follows from the resolver’s attempt to maximize compatibility while staying within the declared ranges.
Confirmed facts

If the version ranges overlap (e.g., one asks for ^1.0.0 and another for ^1.2.0), the resolver succeeds and records the highest overlapping version in Package.resolved.
If the ranges are disjoint (e.g., ^1.0.0 vs ^2.0.0) resolution fails and Xcode shows a version‑conflict error unless one of the packages widens its range to create an overlap.
You can force a specific version by adding an explicit dependency or override in the top‑level Package.swift (e.g., .package(url: "...", exact: "2.3.4")) or by editing the version selector in Xcode’s package editor.
In Instruments, the Build Time template’s “Dependency Resolution” activity measures the time spent in the resolver. To isolate this phase, make sure the packages are already cloned (no network fetch) and clear DerivedData and package caches before recording.

Steps to measure resolver runtime

Close Xcode, delete ~/Library/Developer/Xcode/DerivedData and ~/Library/Caches/org.swift.swiftpm to ensure a clean state.
Open the workspace; let Xcode fetch the packages once (this populates the local checkouts).
Launch Instruments → Build Time template.
Record a build (⌘B) while the template is active.
After the run, expand the “Dependency Resolution” instrument; its duration reflects mainly algorithmic work, as network latency is excluded by the prior fetch.

Missing diagnostic detail
Which Xcode version are you using? The resolver behavior changed in Xcode 13; older versions may pick a lower version or fail differently, which would affect whether an override is needed.

Xcode ↔ Swift Package Manager: Conflict Resolution for Shared Dependencies