Build-tool plugin breaks swift-collections module resolution during xcodebuild archive

[EdmundKorley]

Description

When archiving an iOS project that uses swift-openapi-generator as a build-tool plugin, xcodebuild archive fails with:

swift-collections/Sources/ContainersPreview/Extensions/OutputSpan+Extras.swift:17:8: 
error: Unable to find module dependency: 'InternalCollectionsUtilities'

The same project builds and archives successfully when the OpenAPI generator plugin is removed from Package.swift and the generated sources (Types.swift, Client.swift) are committed directly.

Environment

• Xcode 26.2 (Swift 6.2.3) and Xcode 26.4 (Swift 6.3)
• swift-openapi-generator 1.10.4
• swift-openapi-runtime 1.11.0
• swift-collections 1.4.0 (transitive dependency via openapi-runtime)
• macOS 26 (Tahoe), both local and GitHub Actions CI (macos-26 runner)
• SWIFT_ENABLE_EXPLICIT_MODULES=NO does not resolve the issue

Reproduction

1. Create an Xcode project with a local SPM package that uses OpenAPIGenerator as a build plugin
2. The package depends on swift-openapi-runtime which transitively pulls swift-collections 1.4.0
3. Run: xcodebuild archive -scheme <Scheme> -sdk iphoneos -configuration Release -derivedDataPath /tmp/clean-dd -skipPackagePluginValidation
4. Archive fails with the InternalCollectionsUtilities module not found error

Key observation: The error does NOT occur when:

• Building for simulator (-sdk iphonesimulator)
• Building Debug configuration
• The plugin is removed and generated sources are committed directly
• Using incremental builds with cached DerivedData

It ONLY fails with a clean DerivedData + archive + iphoneos SDK, suggesting the plugin's execution interferes with SPM's build graph ordering for device archives.

Workaround

Pre-generate the OpenAPI sources using the CLI tool, then strip the plugin from Package.swift before archiving:

# 1. Resolve packages
xcodebuild -resolvePackageDependencies -scheme MyApp -derivedDataPath /tmp/bootstrap

# 2. Generate sources via CLI
swift run --package-path /tmp/bootstrap/SourcePackages/checkouts/swift-openapi-generator   swift-openapi-generator generate openapi.json   --config openapi-generator-config.yaml   --output-directory Sources/MyOpenAPIClient/   --plugin-source build

# 3. Strip plugin from Package.swift
# Remove .package(url: "swift-openapi-generator", ...) and plugins: [...] 

# 4. Archive without plugin
xcodebuild archive -scheme MyApp -sdk iphoneos ...

This is what we use in CI, but it adds significant complexity to the workflow.

Related issues

• Archive Fails When Building XCFramework from Swift Package when using swift-collections swift-collections#546 (Archive fails when building XCFramework)
• Archive Fails When Building XCFramework from Swift Package when using swift-async-algorithms swift-async-algorithms#376 (same InternalCollectionsUtilities error)
• Swift Forums: Xcode 26 - Unable to find module dependency

Expected behavior

xcodebuild archive should succeed with the OpenAPI generator build-tool plugin present, same as it does for Debug/Simulator builds.

[Harryjeffs]

I've run into the same issue, and fixing swift-collections to 1.3.0 didn't resolve this either.

[simonjbeaumont]

Thanks for the detailed report. I was able to reproduce this using the HelloWorldiOSClientAppExample in this repo with Xcode 26.4.1 (Swift 6.3) and swift-collections 1.4.1:

swift-collections/Sources/ContainersPreview/Extensions/OutputSpan+Extras.swift:17:8:
error: unable to resolve module dependency: 'InternalCollectionsUtilities'

Seems to also fail in debug for me too (not just release).

This is unfortunate because we don't use ContainersPreview.

This is a swift-collections / Xcode explicit-modules bug rather than something the generator plugin can influence. The BuildToolPlugin API doesn't give plugins any control over how unrelated package targets are built.

I'd recommend chasing this issue on swift-collecitons and/or SwiftPM.

For workarounds, the ahead-of-time generation is sensible and probably the best we can do, short of dropping the collections dependency.