Welcome to a new tutorial where I’m going to show you a practical approach on how to create your own Swift packages. If you’re not familiar with that term, a Swift package wraps up code that can be reused in projects, to be shared with other developers, as well as to be added as a dependency to projects.
Creating and managing Swift packages has been an integrated functionality in Xcode since version 11, and that makes dealing with them a fast and straightforward process.
A Swift package is mainly composed by two parts: The source code which is the heart of the package, and a manifest file, the Package.swift, which is the place where the package configuration takes place. A package can be a dependency to a project, but it can also have its own dependencies, meaning other packages that it is based on. Those dependencies are described in the manifest file. Besides that, a Swift package can exist locally on your computer or remotely, usually as a repository on GitHub. Local packages can be edited while they are integrated in a project, so it’s possible to make changes on them intentionally or not. It’s always a good idea to add a local version of a package to a project during its implementation, but if it’s about just using it, then a remote version consists of a safer and easier approach. Obviously, public repositories containing Swift packages can also be shared with other developers too.
Speaking of sharing packages, responsible for distributing a package around is the Swift Package Manager tool. From the official documentation:
The Swift Package Manager is a tool for managing the distribution of Swift code. It’s integrated with the Swift build system to automate the process of downloading, compiling, and linking dependencies.
Swift Package Manager is what lies behind the scenes and makes it possible to fetch and share Swift packages. It’s not new in Xcode 11; it used to be a command line tool before that. But starting in version 11, Swift Package Manager is integrated in Xcode and makes dealing with packages easy. Please read more about the Swift Package Manager in the official documentation and on its GitHub page.
Note that Swift packages are based heavily on versioning, and to be precise on the semantic versioning standard. For example, 1.2.5 is an example of such a version number, where the first number is the major version, the second is the minor version, and the third is the patch version. I provide a quick description about those numbers later on in this post, but if you don’t feel comfortable with the semantic versioning system then you should definitely read a little bit here.
Swift packages are becoming the new trend, and it seems that other dependency managers are going to meet a strong competitor here. Starting from Xcode 11 the simplified process to create and manage Swift packages has given the advantage to it, and the fact that reusable code can be created in almost no time is what I like the most. With that said, please read on to learn how to create and deal with your own Swift packages through a practical guide.
