SwiftPM proposes unifying package products and targets

Swift Package Manager developers have proposed unifying products and targets into a single primitive in package manifests. The change addresses a longstanding source of confusion over what a package builds versus what it exposes to other packages.

Owen outlined the idea on the Swift forums as a major shift in SwiftPM's build model and asked for early feedback, especially on target visibility and how existing packages would migrate. Under the design, targets would carry visibility such as public or package-scoped, absorbing the role products now play in declaring a package's interface. Existing command-line flags for products would keep working for older tool versions.

The current split often trips up plugin authors, who must reason about automatically promoted executable targets, and vendors of binary frameworks, who wrap dependencies yet still want a clean public name. Those patterns would remain possible by marking a target public instead of routing through a separate product.

Not all feedback endorsed full unification. One developer argued that manifests already serve dual roles as build recipes and artifact bills of materials, and that binary-only packages might be clearer if they declared only products. Others raised practical naming questions: products today let the on-disk artifact name differ from the module name, which matters for C libraries and platform conventions. Owen noted the idea could be considered but would have to respect platform rules, such as Apple frameworks requiring the module name to match the framework name, while command-line tools have more latitude. Build-time SBOM generation would also need to follow the new visibility rules so that a public target continues to produce a bill of materials as a product does today.