A first look at Xcode 11’s Swift Package Manager integration
One of the most exciting new features in Xcode 11 is that the Swift Package Manager is finally becoming a first class citizen within Apple’s IDE. While the new version of Xcode is only in an initial beta stage at this point — it already features an impressive amount of functionality when it comes to building, using, and managing Swift packages.
Let’s take a first look at this new integration, and what sort of features that it currently offers.
Creating and building packages
For Swift package authors (or anyone who wants to start modularizing their code base by moving things into frameworks), Xcode now offers complete support for creating and editing packages. New packages can easily be created using a new
Swift Package option in the
File > New submenu, and Xcode is capable of opening any existing Swift package as well (without requiring an Xcode project file to be generated).
The contents of a Swift package is defined using a
Package.swift manifest file, and editing such files has now been made a lot easier, thanks to proper autocompletion and syntax highlighting. Furthermore, if a new target is added to a package’s manifest, Xcode will automatically pick that up and display that new target within its scheme selector (the caveat here being that, at the time of writing, you do need to manually create folders for each target’s source files).
Swift packages can now (finally!) be used natively in apps on all of Apple’s platforms (they were previously limited to command line tools and server-side Swift applications) — and Xcode can even automatically add a package as a dependency to a project through its
Add Package Dependency option located in the brand new
File > Swift Packages menu. However, interestingly, it seems like dependencies can not yet be added to packages themselves through Xcode — but that’s most likely just a bug or missing feature.
When adding a package as a dependency, Xcode will also automatically scan your GitHub account (if you give it access, of course) and show you a list of the packages that it finds there — making it really quick and easy to pick the dependency that you need. You can even select what version (or branch) constraints that you wish to apply to any added dependency.
You can also specify dependencies by URL, including using
file:// URLs for packages contained on your local machine (which is great when using tools and libraries that you’re currently working on).
Packages for UI, but not for complete apps
Since the Swift Package Manager can now be used to manage dependencies on all Apple platforms, it means that it’s now also possible to build all sorts of libraries using it — including UI frameworks, or any other kind of tool that needs to import platform-specific system frameworks, such as
And, if you ever wish to write platform-specific code in a package while still maintaining cross-platform compatibility, that can easily be done using Swift’s
canImport build-time check:
#if canImport(UIKit) import UIKit #endif
However, Swift packages can not yet be used to completely define app targets (nor targets for things like extensions, or other bundle-based targets). So while a lot of new Swift Package Manager use cases have been unlocked in Xcode 11, the
xcodeproj file format is not completely going away this year.
It’s truly exciting to see the Swift Package Manager finally start to become fully integrated into Xcode, and to be officially supported on all of Apple’s platforms. As someone who has used the Swift Package Manager for years to manage command line utilities, scripts, and server-side applications — I’m really looking forward to having just a single, Apple-provided dependency manager for all of my Swift coding needs.
More first looks at some of the new tools and technologies that Apple has released as part of this year’s WWDC will be coming to this site very shortly — so stay tuned for multiple updates on this site, each day all throughout this week.
Thanks for reading! 🚀