Package.swift manifest: library vs executable products

WHAT THIS TESTS The interviewer checks foundational SPM literacy: that the manifest is the source of truth for a package and that products are the externally visible deliverables built from internal targets.

A GOOD ANSWER COVERS Package.swift is the manifest, executable Swift code beginning with a tools-version comment and importing PackageDescription. It declares the package name, the supported platforms and minimum OS versions, the external package dependencies, the targets which are the units of compiled code with their source paths and per-target dependencies, and the products which are what consumers actually depend on. A .library product groups one or more targets to be imported and linked by other packages or applications; it has no entry point and cannot run by itself. An .executable product builds a runnable binary and is backed by a target that contains a main entry point, suitable for command-line tools.

COMMON WRONG ANSWERS Using targets and products interchangeably; products are the public surface, targets are the build units behind them. Believing a library is independently runnable. Forgetting that the tools-version line determines which Swift features the manifest may use.

LIKELY FOLLOW-UPS What is the difference between a target and a product? When would you mark a library as static versus dynamic? How do test targets fit into the manifest?

ONE CONCRETE EXAMPLE A package defines two targets, NetworkingCore with the implementation and a small CLI target with an entry point that calls into it. The manifest vends two products: .library(name: "Networking", targets: ["NetworkingCore"]) which apps import, and .executable(name: "netcli", targets: ["CLI"]) which builds a runnable tool. An app depending on the package imports the Networking library product, while a developer can run the netcli executable from the command line. The library cannot launch on its own because it has no main entry point.