Swift package collections make curated dependencies searchable

A recommendation in a document tells a developer which library to investigate, but it does not necessarily provide the metadata needed to use it. Swift's June 7 introduction to package collections connects curated recommendations to package tooling. Collections let a publisher distribute a focused set of packages that consumers can search and inspect through SwiftPM.

The availability distinction matters. Tom Doron's announcement describes support in Swift 5.5 previews and Xcode 13 seeds, with the official Swift release still ahead. This is a usable preview of the collection workflow, not a stable Swift 5.5 release announcement. The post identifies collections already published by the Swift Server Workgroup and Apple, alongside dynamically generated collections from Swift Package Index.

I like tooling that reduces the amount of unrelated investigation needed to make a small application build. A curated list can narrow the package selection problem without requiring a new central authority over every package. Its value depends on who maintains the list and what information the tooling can expose about each recommendation.

A collection is a document with useful structure

The SwiftPM documentation available with this announcement defines collections as static JSON documents. Publishers can host them on the web or distribute them to local file systems. This makes the unit of distribution small enough for a course or a particular engineering community to maintain independently.

The metadata can describe packages and versions, including products and targets from manifests. The consumer does not need to infer all that information from a prose recommendation. A development tool can inspect the structure and present the relevant package information through an interface it already provides.

This still leaves curation with the publisher. A collection format can establish that a document is interpretable without establishing that its recommendations suit a particular application. The useful separation is between transporting a recommendation and deciding to rely on it. A trusted curator can make the latter decision easier by supplying a smaller, relevant set of candidates.

Subscription and search share a command interface

The preview's command line supports adding collections and searching imported metadata. The announcement supplies the Swift Server Workgroup collection as a concrete starting point.

swift package-collection add https://swiftserver.group/collection/sswg.json
swift package-collection search --keywords networking

The search term is illustrative. Its results depend on the metadata in the imported collection, so the command does not promise a particular package. The documented search behavior also supports module names, which is useful when the developer knows an import name but not the corresponding repository.

describe accepts a collection URL or a package URL. A version argument requests metadata for a particular package version. JSON output is available for several query commands, allowing other tools to consume the same information without parsing terminal-oriented text. The imported collection contents are also available to clients of libSwiftPM.

list, remove and refresh manage the consumer's configured collections. The refresh operation matters because some queries use local cached data. A successful search describes the metadata available to the local tool at that point. It need not mean that the publisher's latest document was fetched for that individual query.

SwiftPM stores collection configuration in ~/.swiftpm/config/collections.json. The documentation describes it as tool-managed, including the configured list and trust preferences. Keeping management behind commands lets consumers use the workflow without depending on the internal configuration format.

Generation turns a repository list into package metadata

The collection generator project provides generation and validation tooling. Its purpose is to produce and consume documents in the shared format. Using that tooling avoids making every curator implement the metadata model independently.

A publisher's input can be a short list of package repository URLs. Generation expands that list into the collection representation. This separates the editorial decision about which packages belong in the list from the mechanical work of assembling their metadata. Updating the metadata does not have to mean reconsidering the collection's entire subject.

The project also provides a tool to compare collections. That is useful when regeneration changes a large document. A curator needs to understand whether the result represents an intended change to the selection or a metadata update for existing entries. Comparing generated results supplies evidence for reviewing that distinction.

Validation has a similarly specific purpose. A validator can check a document against the expected format, which is necessary for another tool to consume it. That check does not replace the curator's judgement about a package. Publishing a well-formed collection and publishing a useful recommendation are related tasks with different evidence.

Signature checks protect the recommendation document

The SwiftPM documentation distinguishes signed collections from unsigned ones. For a signed document, import verifies the content and the signing certificate's requirements. Importing an unsigned document requires explicit trust through --trust-unsigned. Skipping a signed document's signature check is a separate operation with a different flag.

Certificate roots also affect portability. Apple platforms begin with operating-system roots, while other platforms rely on configured roots and roots shipped with certificate-pinning policy. Publishers distributing to several platforms must account for that difference. The same document can encounter a different trust configuration on another developer's machine.

The documentation describes a stronger publisher policy keyed by the collection URL's host. A publisher can propose requirements for the signing certificate and require signing for collections on that domain. The review process asks for certificates and proof of domain control through a DNS TXT record referring to the pull request. Accepted policy takes effect in a subsequent SwiftPM release.

That process ties a collection location to an expected signer. A valid signature alone does not establish that the signer is the intended curator. Host-specific restrictions address that association, including attempts to remove a signature or substitute another valid signing identity.

I regard collections as useful precisely because their scope remains explicit. They make a chosen set of recommendations available to package tools. Signature policy can protect that document's provenance, while the package's implementation and suitability remain subjects for engineering judgement. The preview now gives publishers and consumers a concrete workflow for exchanging that curated metadata.