SwiftPM accepts deployment versions without platform restrictions

A list named platforms can look like a list of the only systems a package supports. That interpretation is specifically outside the Swift Package Manager proposal accepted today. The accepted design customizes minimum deployment versions and leaves platform restrictions for separate work.

Boris Buegling's November 30 acceptance announcement explains the revision. Reviewers gave substantial negative feedback on the platform-restriction portion of SE-0236. The SwiftPM code owners accepted a version limited to deployment targets. The decision also replaces a verbose version-construction initializer with a string overload.

The proposal by Ankit Aggarwal addresses a real mismatch between library requirements and package configuration. SwiftPM has a hardcoded macOS deployment target, while packages may need APIs introduced after that version. A manifest declaration gives the package a place to record that requirement.

I prefer constraints that travel with the code that needs them. A deployment setting supplied only through a build command leaves another consumer to rediscover it. SwiftPM's accepted direction makes the requirement part of the package description, while keeping its meaning narrower than a claim about every supported operating system.

A minimum version is an API assumption

The deployment target states the earliest platform version for which the package is being compiled. A package using newer APIs needs either appropriate availability handling or a minimum version that permits those APIs. The proposal identifies availability checks and command-line deployment arguments as existing workarounds.

Those workarounds express different intentions. Availability handling can retain an older deployment target while accounting for an API that may be absent. Raising the deployment target changes the minimum operating-system assumption for the package. A manifest API lets the author state the latter directly.

The accepted design adds SupportedPlatform values to the package initializer's platforms field. Despite that type name, these declarations customize version requirements. They do not say that an omitted platform is forbidden.

The following is an excerpt illustrating the accepted declaration syntax. It describes the proposed manifest API, rather than a promise that an existing released toolchain already accepts the new field.

platforms: [
    .macOS(.v10_13),
    .iOS(.v12)
]

The proposal says this chooses macOS 10.13 and iOS 12.0, with default deployment versions elsewhere. That final clause is the important part of the interpretation. An omitted platform retains default behavior under this design.

Dependencies must fit the root package's minimum

Deployment versions also constrain the package graph. The proposal requires a dependency's minimum deployment target to be no higher than the top-level package's target for the same platform. SwiftPM emits an error when the dependency is incompatible.

For example, a top-level package promising an older macOS minimum cannot satisfy that promise by incorporating a dependency requiring a newer macOS version. Successful dependency resolution alone does not establish that the resulting package graph meets the top-level deployment requirement. The deployment check supplies another compatibility condition.

The proposal does not include deployment-target requirements in version resolution to search automatically for an older compatible dependency release. Its alternatives discussion considers that possibility and declines it. The intended behavior is an error for an incompatible selection, not a silent search for another version.

This means authors should treat a higher minimum deployment target as a breaking library change. SE-0236 explicitly connects such changes to major semantic-version updates because dependent packages may stop being compatible. A library's public compatibility commitments include where it can run.

That consequence is easy to miss when a source API remains unchanged. A dependency can retain the same function declarations while becoming unusable for a consumer's oldest supported operating system. The manifest makes that incompatibility expressible even when an ordinary source comparison shows no removed method.

Each package retains its declared target

The design compiles each package with its own deployment version. It considers using the top-level version throughout the graph, since every dependency must already be compatible with that version. The proposal declines to make that the default model.

One reason given is diagnostic behavior. Compiling a dependency with a higher deployment target can produce warnings that were absent under its declared target. Preserving each package's own setting keeps its compilation tied to the environment the author described.

The proposal also states that generated Xcode projects should receive the deployment versions. This matters because a package's declaration should remain meaningful when a developer works through a generated project. Otherwise the project and command-line workflows could use different platform assumptions.

My concern with Swift build configuration is less about adding another field than about avoiding independent copies of the same decision. A package's minimum version should have one declared meaning across the workflows that consume the manifest. The proposal assigns the package manager the work of applying that declaration.

Version strings cover values outside the named constants

Named constants make common deployment versions readable, but they cannot anticipate every future platform version or useful patch version. The design therefore includes string overloads. The acceptance announcement explicitly chooses .macOS("10.13") over wrapping a string in a separate MacOSVersion initializer.

Invalid versions produce manifest parsing errors. The proposal also identifies duplicate platform declarations and an empty platform array as invalid cases. These checks keep malformed configuration distinct from an incompatibility between otherwise valid package declarations.

The new APIs require an updated package tools version when implemented. Existing packages retain their current behavior, including SwiftPM's default deployment assumptions. Acceptance is therefore a design decision with a compatibility path, rather than a requirement that every existing manifest immediately declare platform versions.

Platform selection remains separate

SE-0236 leaves several related problems unresolved. It does not select targets or products by platform, and it does not introduce platform-specific package dependencies. A package requiring different products on different systems still needs another mechanism for those distinctions.

The accepted revision also leaves the restriction of supported platforms outside its scope. This is the central correction to reading platforms as an allowlist. The proposal provides minimum-version customization, with defaults for omitted platforms. A package author can now describe the intended deployment requirement in the accepted design without claiming that the same declaration excludes every unnamed system.