Xcode Cloud Dependency Resolution - out-of-date resolved file

When I try to build my iOS app using Xcode Cloud, it encounters an error when trying to resolve packages:

an out-of-date resolved file was detected at [path to package.resolved], which is not allowed when automatic dependency resolution is disabled; please make sure to update the file to reflect the changes in dependencies

Looking at my package.resolved file, it all seems to be in order. What can I do to fix it?

Post not yet marked as solved Up vote post of KuriiboShoe Down vote post of KuriiboShoe
4.3k views
  • I am also hitting this problem. Package.resolved file has not changed according to source control, yet xcode cloud errors out because it says the package.resolved file is out of date

Add a Comment

Replies

I have the same issue. Did you find a solution?

I got around this by adding another dependency which caused Xcode to somehow also cause a change for an unrelated package in the Package.resolved file which was already there. Just asking Xcode to resolve packages wasn't enough to trigger this.

Same issue here. Regenerated package.resolved, updated package versions, reset cache, reset schemes, added another dependency still having this issue. Don't have this issue with another application using Xcode Cloud.

I have a similar issue. In my case, there is a package called GraphicsRenderer causing problems. During build, either Xcode Cloud or a fresh local build (done after xcodebuild clean), xcodebuild will claim it finds a new package called graphicsrenderer (the case matters here), but new package is not allowed when automatic package resolution is disabled. Then a fatalError is triggered and the build failed.

Below is all speculation. I believe due to some bug in either Xcode or SwiftPM, xcodebuild treats GraphicsRenderer (which is the name recorded in my Package.resolved) and graphicsrenderer, which is the default name derived by Xcode, as two different packages. By the way, I failed to modify my Package.resolved to make Xcode believe they are the same thing. Notice that locally, a second run can happen smoothly, probably because some cache that helps Xcode correctly identify the two as the same thing.

I found a not very practical workaround when attempting to creating a minimal case to report to Apple. That is, recreating your Xcode project using Xcode 14. It seems that a version 2 Package.resolved has been put in use since Swift 5.6. In that format, I can see there is an identity for each resolved package, and GraphicsRenderer has that field set to graphicsrenderer. I no longer face any issue. But I cannot get xcodebuild to generate a version 2 Package.resolved for my existing. My guess is that for any Xcode project, there is a minimum compatibility specified. My old projects were created with Xcode 13 and thus locked the version 1 Package.resolved.

By the way, I have zero idea when this issue might occur. It certainly won’t happen for Apple packages, which all adopt an all lowercased naming such as swift-markdown. But this didn’t happen for GRDB and many other packages with capital letters.

Any update on this? I'm facing the issue while the project has a minimal number of dependencies...

Also hitting this problem myself.

Not sure if this will help anyone else, but just in case I'm posting how I was able to address it when I ran into this issue. The root cause was a conflict between a version specified in Package.swift and the Package.resolved file. The Package.swift file had just been updated to use the package(url:exact:) call for the dependency instead of package(url:from:) after running into an unrelated issue where local builds were using a newer version of a dependency than was specified in the Package.resolved file (so, what was used in Xcode Cloud). Unfortunately, Xcode wouldn't update the Package.resolved file after doing this change for some reason, and that fact was missed when those changes were checked in. I had to quit Xcode and run swift package resolve in terminal to get the file updated. Once this was checked in, the error was resolved.

As a tangentially related side note - I was constantly running into differences between the Package.resolved file in the root of the project vs. the one inside the workspace. To get around this, the workspace version was added to the .gitignore, and then in Xcode Cloud's ci_post_clone.sh script I copy the root project into that location. Now I only have to worry about keeping one file up to date.

Running xcodebuild -resolvePackageDependencies resolves the issue for me.