Swift Cocoa: Package Management
When I began iOS development, there was only one package manager. But now developers have the option to choose between Cocoapods, Carthage, and SwiftPM. Each has their own principles and implementation.
There exist some differences that are important to understand. One of those differences is between centralized and decentralized managers. When creating a CocoaPod, we submit to an ecosystem of pods and developers. Other developers are able to look around published CocoaPods online. This is a centralized system of package management. In the past, it has taken a few hours after publication to find my pod.
When developing a Carthage framework or Swift package, the manifest file is declared on top of the library. Other developers are NOT able to look online at existing SDKs that declare support. Instead developers build libraries from their reference to some manifest. For now Carthage is the only decentralized manager with shorthand for GitHub hosted libraries. But Carthage also requires an additional manual installation step when compared to SwiftPM.
The better libraries include support for all three package managers. This is because some apps require dependencies that do not allow CocoaPods. And while I believe Carthage is the true substitution to CocoaPods, I am led to believe that SwiftPM will soon become the decentralized norm. SwiftPM has only been around since Swift 3, which was released a little under 3 years ago. Carthage has been around a little longer, it is 4 years old.
Today it is easier to declare a Cartfile than a Package because there exists features for continuous integration and GitHub hosting. But in the future I expect SwiftPM to release meaningful features for developers. As a part of Xcode, SwiftPM has a chance to be a powerful shortcut with native support. Due with the next the release of Swift 5, will be support for backward compatibility; which will make Swift frameworks more practical for release. As it stands, if you develop a framework using Swift 4.1; there is no using Swift 4.2 to compile your framework.
Develop your frameworks! But as it stands you may be stuck writing support for multiple package managers. There is something comforting existing in cocoa libraries that have multiple installations paths. It's impossible to judge the dependencies of unseen projects, to combat the unknown; SDKs give developers lots of ways to do setup properly.