I have a workspace with a good amount of dependencies, both local and remote (and the local dependencies also exist as remote dependencies as a convenience for being able to edit several packages I work with from within the same Xcode workspace).
Here are the logs from the first steps of an incremental debug build. The “Compute … for package preparation” step took 1.284 seconds, “Send project description to service” 0.774s, “Compute target dependency graph” 1.359s. This adds up to 3.4s out of my 5.5s build which is frustrating. Is there any way I can optimize this without moving to xcframeworks? Is it recalculating all this from scratch each build because I have a few local dependencies? The local dependencies as you can see below in turn include most of the remote dependencies.
On Xcode 26 the first ~5 seconds of my builds (out of 10 seconds total) go to computing target dependencies. Is there any good strategy for reducing this?
What worse is that, for all the slow work that phase does, it doesn't properly handle simple cases like needing to rebuild a dependency as a dynamic framework when I switch from just building a watch app to the iOS app that embeds it, where both need the same underlying dependency. I'd be more okay with slow analysis if it was actually accurate, but it's not, so I end up having to repay it over and over again as I clean and rebuild.
Only 2 seconds? I raise you 125 seconds. It takes Xcode literally more than 2 minutes to compute the dependency graph on a project I work on. We’d love to know why. We’ve been simplifying the project considerably and it still takes 2 minutes.
There definitely seems to have been a major regression in planning performance in Xcode 26 / 26.1. In one of my small projects it barely showed up in Xcode 16.4, now it's plainly visible across the project and all dependencies. Even tiny packages have 1.6s planning phases. Not to mention Xcode 26.1 now has a visible "Build stat cache" step that takes 5s on an M3 Ultra every build.
Just confirming that this is still the case in Xcode 26.2 beta 1 in the project that @Oliver_Jones mentioned above (and other projects that we both work on).
We are seeing the “Compute target dependency graph for package preparation” ComputePackagePrebuildTargetDependencyGraphstep take over an hour for our large Xcode projects (>700mb) using Xcode 26.0.1 and 26.1.1.
From spin dumping SWBBuildServiceand tracing execution of a dev version of SWBBuildServiceI am seeing that simply reading a message over a socket is what is taking up so much time (the loop here). The specific message that is taking so long is the TRANSFER_SESSION_PIF_OBJECTS_LEGACY_REQUEST message which for one of our projects is receiving 736.24mb for that one message.
I can also reproduce the issue with a dummy xcode project where I dramatically inflated the project size by editing a scheme to add OTHER_SWIFT_FLAGS = "-warn-concurrency -warn-concurrency -warn-concurrency [maybe 100,000 more times]". Will file a Radar with the dummy project to hopefully get more visibility to this issue.