Offering this here for those who may run into the same issue... There is more than one reason you may get the following error message when attempting to build your targets: Cycle inside ...; building could produce unreliable results But if you just switched to Xcode 15 and you are currently customizing DSTROOT to set the root install location for the deliverables (app, bundle, etc) built by your Target, Xcode 15 will refuse to build any target with dependencies on other targets that use the same underlying configuration. There is obviously no real cycle: Xcode 15 is just confused by both targets sharing the same DSTROOT. For example, if you set up your projects with: DSTROOT=/ INSTALL_PATH=/Applications (notice that DSTROOT=/ is even mentioned in the docs) Xcode will wrongfully detect a circular dependency as both targets share the build destination and thus refuse to build. The solution is to not customize DSTROOT, thus allowing it to have a directory name that is target-dependent and thus fairly immune to collisions. Instead, customize the INSTALL_ROOT setting. While this setting does not appear in the Build Phases tab, it defaults to reusing the DSTROOT value. If you set it explicitly, it allows DSTROOT to remain for other purposes, while using the value of INSTALL_ROOT to deploy your deliverables: INSTALL_ROOT=/ INSTALL_PATH=/Applications This allows the build system to proceed without errors.

The Xcode 13 Beta (1 & 2) is showing some serious performance regressions when building our large project, and wondering if others are noticing the same. If you Build again after a build had just completed, Xcode 13 redoes a ton of work, as visible through the thousands of tasks it takes on. It's as if Xcode 13 lost the ability to skip unnecessary work. Building again in Xcode 12 does incur a small penalty too, but the difference is between 2-3 seconds (Xcode 12) vs 1-2 minutes (Xcode 13). ...and as a side note, the new progress reporter is useless: it switches from reporting progress for one set of tasks (1928/3022 completed) to a completely different set of tasks (444/1255 completed). You never know which "set of tasks" is the last you'll need for the build process as a whole to be done. Any idea why it doesn't display cumulative progress? Thanks!