What is it and why use it?


For years, package management with Swift has been done with (often clunky) CocoaPods or Carthage tools. With Xcode 11, the Swift Package Manager is accessible to the general public… but what is it and how to use it?

The Swift.org website succinctly describes the Swift Package Manager (SPM): “A tool for managing the distribution of Swift code”. But we could do it already, so why is SPM better? And should you replace your CocoaPods, Carthage, or GitHub workarounds to implement it?

Let’s walk through the Swift Package Manager.

What is a package?

GitHub rest, pods on CocoaPods… these are the two packages! Any code package hosted in a repository is a package. This could be an executable API, a standard library, or whatever snippet you need in your codebase (or multiple codebases).

Via GitHub (and Medium), Apple describes SPM as “a source code distribution management tool, aimed at making it easier to share your code and reuse others’ code.” It really is that simple. This is one of those (rare?) Times engineers weren’t too smart about a naming scheme.

How to create a package?

You can choose one of two ways: local or public.

A local Swift package is basically code that you want to use globally, but not post to GitHub. If you have a code hosted in a .Swift file in a project, make sure that file is highlighted, then go to File> New> Swift Package.

Choose a name to save the file to and “add” it to the project. The “group” you save it in is where things get a little tricky; you’ll want to add it to the root group it’s in, not to a file elsewhere. Remember, you want this to be available worldwide for your project!

Xcode will create the package, complete with a ReadMe file and Package.Swift to file. Impressive!

To publish the package to GitHub (and remember that a GitHub repository can be public or private), first select the package (not the file!) In your Xcode project. Drag it to your desktop, hold “option” to create a copy of the package file, and drop it on your desktop. Then open it in Xcode as you would any other project (double-click the folder, then double-click the Packages.swift to file).

(You may want to take this time to add text to the readme file, or add license information. Or both!)

In the Open Source menu bar control, select “Create Git Repository”. Your project is probably already under source control. If so, Xcode will tell you that everything is fine. Otherwise, just select your project from the menu and continue.

Go to the source control browser (the small target icon in the navigation area) and right click on your project file. Select “Create (project name) remotely” and select the account you want to add it to.

Note: If you do not have an external account configured in Xcode, in the menu bar, go to “Xcode> Preferences> Accounts”. Select the “+” at the bottom left and add your account (s).

How to manage a Swift package

So you’ve written some smart code and released a package. You do it well! But what if you make changes?

It’s actually quite simple. First of all, don’t forget to make changes to the actual package file in Xcode; open it as a stand-alone project. This is where you will manage your package.

For the sake of argument, let’s say you have a package for the game controls. You changed this after beta testers provided feedback. When you are in the source control browser, right click on your project and select “Tag Master”. Mark your version change and add notes.


To commit your changes to a GitHub repository, select “Source Control” from the menu bar, then “push”. It will ask you which branch of the repository you want to send the changes to (if you or someone else forced it, of course), and allow you to include the tag you just added. Then just select “Push”.

How to add a Swift package to your project

You now know how to create and manage your own package. Impressive! But what if you want to add a package that you found on GitHub?

It’s really easy. In your project, navigate to File> Swift Packages> Add Package Dependency via the menu bar. A pop-up titled “Choose Package Repositories” will display all the GitHub files that you have access to (if you don’t see it listed, you can add a repository to your project through its URL).

After selecting the repository you want to add to your project, you can define rules. You can granularly control which versions of a repository you want to use, as well as which branch you want to check out (or commit) from.

When you add a package to your project from GitHub or another source, you will see a new section in the file browser called “Swift Package Dependencies”. If you also have a local version of your package in the project (you know that cool thing you created and then turned into its own package?), Delete it from your main branch. You want the SPM to manage your packages, and having both the locally hosted version and the version controlled on GitHub can cause issues.

In your targets, you will want to add the package under “Frameworks, Libraries and Embedded Content” using the “+” at the bottom left.

Why should you use Swift Package Manager

SPM relies heavily on two major pillars for iOS developers: Xcode and GitHub. You can also use Bitbucket or GitLab.

It’s also as official as package management will be. Appel is developing Swift as an open source project, and Swift Package Manager is one of them. Meanwhile, Microsoft owns GitHub. Neither Apple nor Microsoft are going anywhere soon.

As you can see, creating and managing your own packages is pretty straightforward. It really is as easy as taking a file .swift and turn it into a standalone project, then publish it. Changes can be pushed directly to your hosted repository, and you can manage them however you want.

Xcode also helps troubleshoot issues. Since SPM is a product closely related to Xcode, it helps solve problems much better than other package management tools (others force Xcode to raise its proverbial hand).

Perhaps more importantly, it makes supporting a package very easy. You use the IDE you know (Xcode) and treat a package like any other Swift project. Good luck!


Comments are closed.