NIOCore fails to resolve DequeModule/Atomics module dependencies during a real build (pbxproj already wires them correctly)

Metadata

Source

tuist/tuist #12589

Updated

Aug 25, 2026

Domains

Generated projects

Details

What happened?

A plain xcodebuild build of an app target that depends (directly or transitively) on swift-nio’s NIOPosix product fails while compiling NIOCore:

error: Unable to resolve module dependency: 'DequeModule' (in target 'NIOCore' from project 'swift-nio')
error: Unable to resolve module dependency: 'Atomics' (in target 'NIOCore' from project 'swift-nio')

DequeModule comes from swift-collections, Atomics from swift-atomics — both are resolved dependencies in the graph, and the generated project.pbxproj already lists DequeModule.framework/Atomics.framework as build-phase dependencies of the NIOCore target (confirmed by grepping the generated pbxproj for DequeModule.framework in Dependencies / Atomics.framework in Dependencies — 8 matching edges are present). The dependency graph edge exists in the generated project; the framework just isn’t available/built yet when NIOCore’s own compile step tries to import it.

This reproduces with a minimal app target — no App Extension, no custom build configurations, no PackageSettings overrides, nothing beyond a single app target depending on NIOPosix.

Originally found in a larger project (migrating from XcodeGen to Tuist) where the same error appeared through an internal package’s own dependency on swift-nio. Isolated down to just swift-nio + NIOPosix — see the minimal reproduction repo linked below.

Reproduction repository

https://github.com/o-nnerb/tuist-nio-dequemodule-repro

How do we reproduce it?

tuist install
tuist generate --no-open
xcodebuild build \
  -project SampleApp.xcodeproj \
  -scheme "SampleApp" \
  -destination "generic/platform=iOS Simulator" \
  CODE_SIGNING_ALLOWED=NO \
  CODE_SIGNING_REQUIRED=NO

Error log

/.../Tuist/.build/checkouts/swift-nio/Sources/NIOCore/AsyncChannel/AsyncChannelHandler.swift:15:8: error: Unable to resolve module dependency: 'DequeModule' (in target 'NIOCore' from project 'swift-nio')
    note: A dependency of main module 'NIOCore'
    .../Sources/NIOCore/AsyncSequences/NIOAsyncSequenceProducer.swift:15:8: note: Also imported here
    .../Sources/NIOCore/AsyncSequences/NIOAsyncWriter.swift:16:8: note: Also imported here
    .../Sources/NIOCore/AsyncSequences/NIOThrowingAsyncSequenceProducer.swift:15:8: note: Also imported here
/.../Tuist/.build/checkouts/swift-nio/Sources/NIOCore/AsyncSequences/NIOAsyncWriter.swift:15:8: error: Unable to resolve module dependency: 'Atomics' (in target 'NIOCore' from project 'swift-nio')
    note: A dependency of main module 'NIOCore'
    .../Sources/NIOCore/FileHandle.swift:15:8: note: Also imported here
error: Clang dependency scanning failure: (in target 'NIOCore' from project 'swift-nio')

macOS version

27.0 (Build 26A5421a)

Tuist version

4.205.0

Xcode version

27.0 (Build 27A5237l)

Flights

Investigate, reproduce, or fix this item in an isolated repository. Each Flight preserves its outcome and agent session.

New Flights are paused Configure model inference, GitHub, and a sandbox provider to start another Flight. Existing results remain available below.

No Flights yet

Start a Flight and preserve its objective, outcome, and session here.

Comments

D

dosubot[bot] Aug 25, 2026

@o-nnerb this looks directly related to #11770, which identified that Tuist-generated workspaces are missing cross-package target dependency edges [1]. The root cause described there is that dependencies crossing package-project boundaries don’t get real build-ordering edges — ordering relies on implicit mechanisms (search paths, scheduling timing) rather than explicit target dependencies. When timing doesn’t work out, the compiler hits Unable to resolve module dependency because the upstream framework hasn’t been built yet, which matches your error exactly.

Since this is a generator-level issue, the recommended next step is to install the debug-generated-project skill and use a coding agent (Claude, Codex, Amp, etc.) to dig into the generated project — it walks through exactly the kind of build-phase and dependency-edge analysis needed here [2]. Your minimal reproduction repo is a great asset for that.

You may also want to link this issue to #11770 for tracking, since both reports converge on the same missing cross-package dependency edges problem.

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

ON

o-nnerb Aug 25, 2026

Confirmed this looks like the same root cause as #11770 — and this repro is a clean instance of the primary mechanism described there (not the “synthesized target” edge case), worth noting:

DequeModule and Atomics do exist as real PBXNativeTargets, each in their own generated project (swift-collections.xcodeproj, swift-atomics.xcodeproj respectively) — not synthesized/placeholder targets.
swift-nio.xcodeproj (which builds NIOCore) has zero references to either project as a subproject, and zero PBXTargetDependency entries with remoteInfo pointing at DequeModule or Atomics. grep for both across the whole .pbxproj comes back empty.
The only thing connecting them is the “DequeModule.framework/Atomics.framework in Dependencies” build-phase link entry (confirmed 8 matches) — a link-time search-path hint, not a build-order edge.

So this matches #11770’s description exactly: a target in one generated package-project depends on a product of another package-project, and the generator emits the link-phase reference but no explicit target-dependency edge to order the two projects’ builds. Since real native targets exist on both sides here (no synthesized-target complication), this might be a simpler case to use for validating a fix than the NIOCore/NIOHPACK case mentioned in the latest #11770 comment.

Linking for tracking: this is likely a duplicate (or at least a directly related instance) of #11770.