Swift Package Contracts

Treat packages as consumer contracts proved outside implementation modules and bound to release evidence.

Contract

Record tools/language modes and Swift settings, products and every target kind, explicitly supported platforms/floors, delivery form, host needs, exact baseline, and version policy including pre-1.0. Contracts include names, declarations, protocols, constraints, Codable forms, availability, resources, behavior, isolation, and Sendable. Do not mistake SwiftPM's implicit platform defaults for an intentionally supported test matrix.

Route detail to package boundaries, public contracts, or verification and release.

Invariants

• Products are consumer-visible; targets are build-graph units. Distinguish regular, executable, test, binary, system-library, plugin, macro, and other supported target kinds instead of assuming each target compiles source or tests. Export supported modules only, normally leave linkage unspecified, narrow dependencies, and keep implementation types out of signatures. Treat name/floor changes as migrations; build conditional graphs on real platforms.
• Classify source, binary, wire, behavioral, and concurrency impact. Additive overloads, requirements, conformances, constraints, defaults, or isolation can break clients; compile old call sites.
• For durable data, use explicit keys, define missing/unknown/renamed fields, and test historical old/new fixtures. A current round trip does not prove compatibility.
• Sendable, actors, async, callback isolation, cancellation, and completion are API. Prefer checked conformance; require a synchronization proof for public @unchecked Sendable.

Evidence and release