I moved my project from Cocoapods to SPM… Why?

Ever since Apple officially launched Swift Package Manager with XCode 11 and Swift 3.0, I’ve been looking forward to incorporating SPM into my projects but also I’ve been dreading the transition. Even if you aren’t wondering why, I’ll tell you anyway but before that, let me try to explain what exactly SPM is and does.

Swift Package Manager is a tool for managing distribution of source code, aimed at making it easy to share your code and reuse others’ code. This has become Apple’s official package manager. I’ll always recommend that you read Swift documentation because they are really good and then you can supplement that with third-party submissions like mine for relatability and context. Find article here.

Cocoapods and Carthage have been go-to options for integrating third-party frameworks and libraries with the former being the widely used option. They all provide the service of creating reusable code, organizing it in a lightweight form, and sharing it across Xcode projects and with other developers.

Image from Apple Developer

The Why answer

One may think, if it’s not broken don’t fix it; so what is the motivation for transitioning from cocoapods to SPM? Well, SPM offers a more streamlined and native solution for dependency management in Swift projects but it’s not just that so I’ll expound on it a bit more.

1. Native Integration

It’s hard to beat native integration into a reliable ecosystem and that is one of the most compelling reasons for SPM transition with Swift & Xcode development environment. Whilst Cocoapods and Carthage require additional setup and configurations, SPM plugs directly into Xcode simplifying the dependency management process, providing ease through its straightforwardness and less errors. A lot of developers on Xcode 14 have been running into (solvable) issues (error sample below) with their pod configurations and the most recent one I encountered and normally happens when a dependency is not updated. With SPM, adding, updating and removing dependencies directly from Xcode is seamless. More on this issue here.

Command PhaseScriptExecution failed with a nonzero exit code

2. Standardization

SPM complies with Swift Package Manager API and manifest requirements which provides a standard approach to dependency management. The perk here is the consistent behavior you experience across projects which promotes convenient collobaration and code sharing. You’re freed from scripts and plugins that are less stable and reliable when compared.

3. Swift-Centric Ecosystem

Generally, Apple has one of the best ecosystems in digital technology (but maybe it’s just my bias leaking in this closure — ha!) and that translates into Swift and SPM as well. The sole responsiblity of SPM is managing Swift packages and dependencies. The ecosystem’s advantage here is ensuring compatibility, optimizing building and resolving dependencies. Swift Package Index, a centralized repository for Swift packages is integrated in SPM and it plays a big role in accelerating development and collabroation through its extensive collection of Swift packages.

4. Dependency Resolution & Improved Build Perfomance

You encounter conflicts and compatibility issues sometimes using Cocoapods or Carthage, SPM’s dependency resolution algrorithm is pretty robust and reliable such that its version-based approach consistently ensures right dependecies are fetched and built.

Since switching to SPM, build performance has increased significantly. I later found out that SPM leverages Swift’s build system and incremental compilation feature to minimize build times. This is directly proportional to iteration cycles so it’s an up for productivity with a reasonably short wait time.

I know, I’ve made SPM sounds like the ultimate solution with no blemishes but that is entirely not the case.

• SPM currently doesn’t support all the platforms ie. iOS, watchOS or tvOS
• You also have to follow a specific folder structure. Even though that increases consistency and ease of use, it reduces flexibility and brings complexities to legacy project integrations especially.
• There are also tool limitations with using SPM since it’s tightly coupled to Xcode. The seamless integration and features available in Xcode may not be accessible with other IDEs (why are you not using Xcode though?)

There’s a curveball in this transition you may or may not encounter depending on the packages you use and how often they are updated. I however will not recommend that you have both cocoapods and SPM in a project, you can end up with undefined behavior and crashes when you have module reliance from either a pod or Swift package.

This probably begs the question, how did you handle dependencies that aren’t SPM compliant yet?

In my bid to move completely away from cocoapods, I initially moved all SPM compliant libararies to use SPM and then found alternatives of other libraries which didn’t support SPM. However, this wasn’t 100% successful as I was still left with a few libraries. In my case, they weren’t too heavy and had few files so I moved them into a dependency folder section in my project (Do this with caution… please), used them directly and deintegrated cocoapods from the project with these terminal commands:

$ sudo gem install cocoapods-deintegrate cocoapods-clean
$ pod deintegrate
$ pod cache clean --all
$ rm Podfile

Below is a screenshot on how to add a framework or library using SPM. Open your Xcode project, navigate the File tab within the macOS bar, and click on “Add Packages”. The second screenshot shows the alternate option of adding or removing a package. This can be located in Project section -> Package Dependencies tab

Screenshots on adding and removing frameworks using SPM respectively

Swift Package Manager provides a range of benefits to Swift developers who desire a streamlined and effective approach to managing dependencies as mentioned above. While Cocoapods and Carthage have been valuable to the community and still is, transitioning to Swift Package Manager offers fresh opportunities and aligns with the evolving Swift ecosystem. As the Swift community embraces SPM, developers should contemplate making the switch to unlock the advantages of a contemporary and native dependency management solution.

Fin.