The Package.swift Manifest File
Think of Package.swift as a recipe for your code, telling the Swift Package Manager (SPM) what to build, what it needs, and where it can run. You use it to define libraries, list dependencies, and set minimum OS versions.
WHY IT EXISTS Swift needed a decentralized, convention-over-configuration way to manage dependencies and build configurations. The Package.swift manifest allows a project's structure and dependencies to be defined in a single, readable, and version-controllable Swift file, replacing older, more complex project file formats.
THE MENTAL MODEL Think of Package.swift as the blueprint for a software project. It's a formal declaration, written in Swift, that tells the build system (the Swift Package Manager or SPM) everything it needs to know: the project's name, the products it creates (like a library), the other packages it depends on, and the OS versions it's designed to run on.
HOW IT WORKS The file is executed by SPM. It must start with a // swift-tools-version: comment, which locks the version of the PackageDescription API. The rest of the file imports PackageDescription and initializes a single Package object. This object's initializer takes several key parameters: name for the package, platforms for supported OS versions like .macOS(.v12), products for what the package builds, dependencies for external packages, and targets for the source code modules.
WHEN TO USE IT Use a Package.swift file whenever you create a reusable Swift component (a library) or a command-line tool. It is the standard for sharing code in the Swift ecosystem. You will edit this file to add a new dependency, create a new module (target), or update the minimum OS version your code supports.
WHEN NOT TO USE IT While SPM is increasingly used for apps, Package.swift doesn't fully replace Xcode's .xcodeproj for complex iOS or macOS applications with intricate build settings or capabilities tied deeply to the Xcode GUI. For simple dependency management in an app, it's great, but for project-level configuration of a GUI app, you'll still primarily work in Xcode.
ONE CANONICAL EXAMPLE A common setup defines a library product. The products array will contain .library(name: "MyLibrary", targets: ["MyLibrary"]). The targets array will then have a corresponding .target(name: "MyLibrary", dependencies: []). To use an external package, you'd add .package(url: "https://github.com/some/repo.git", from: "1.2.3") to the main dependencies array and add the package's product name to your target's dependencies array.
Read the original → docs.swift.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.