So for quite some time, I had the Swift Build System Integration flag enabled to speed up my builds. It was good. I set it, it worked, I forgot about it.

With Xcode 13.3 and 13.3.1, now, we got a lot of dependency cycle warnings out of nowhere. Clean build works, but any build afterwards would occasionally fail.

With 13.3.1 that I downloaded today, this happened for every build after a clean build. Each and every one after the first build after a clean! Oof.

Here’s just one example, so you know what I’m talking about; it has nothing to to with Sparkle. Sparkle is fine. It’s Xcode that is drunk.

Cycle in dependencies between targets ‘Sparkle’ and ‘SparkleDownloader’; building could produce unreliable results. This usually can be resolved by moving the target’s Headers build phase before Compile Sources.
Cycle path: Sparkle → SparkleDownloader → Sparkle
Cycle details:
→ Target ‘Sparkle’ has target dependency on Target ‘SparkleDownloader’
→ Target ‘SparkleDownloader’ has link command with output ‘…’
→ Target ‘Sparkle’ has link command with output ‘…’

So I looked this up real quick, and no – I cannot order the “Headers” build phase above the “Compile Sources” build phase, because in a pure Swift project, the “Headers” build phase doesn’t even exist on the offending targets. (I tried to use this on all other modules, though, but most were already in that order; and those that weren’t had no effect.)

The Apple Dev Forums produces an interesting hint about the aforementioned EnableSwiftBuildSystemIntegration flag – which, contrary to the actual tip, I turned off.

defaults write com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration 0

And this worked!

I don’t know why one person needs to enable this while another has to disable it, but well, there you go – if in doubt, turn it to not-whatever-your-value-is.

$ defaults read com.apple.dt.XCBuild EnableSwiftBuildSystemIntegration
0