Relationship between a Swift Package and the SwiftPM

Using Swift
,
1

It seems to clear to me that the capabilities of Swift Packages extend far beyond the use case of it as a way to share code with others. This is based on reading Documentation and also trying them out myself.

Specifically, it’s possible to use Packages purely for modularising your codebase, without any thought for exporting the packages to be used for outsiders, to take advantage of the access controls benefits provided by Swift Packages framework . In this usecase, all the Packages are local and theres no versioning involved. SPM is only there to check for circular dependencies.

Yet the official documentation only discusses the Swift Package as part of the section on Swift Package Manager, which is a dependencies management framework.

As I see it, Swift Package is more than just a file format to help SPM to resolve dependencies for a host app — it is its own concept, for developers who want to modularise their codebase to have more control over what’s exposed to the rest of the code.

I think because Swift Packages are only discussed in light of SPM, the misconception is that it is just the equivalent of a Pod for the CocoaPods framework.

2

You could also use CocoaPods to modularize with local Pods, so the comparison holds. The biggest issue with using SPM as a local modularization solution is Xcode. Packages don't, and can't, inherit the project settings you need. You don't get control over build architecture (despite the recent Xcode scheme setting that claims to do so), nor any other settings, which CocoaPods provided as a vital tool against Xcode's frequent bugs. But even if SPM's capabilities in those areas were enough, they can't do something like automatically pass through active build conditions or unify build configurations, making it fairly useless for projects of any complexity.

As for why no one consumes Package.swift files in other tools? They're written in Swift, so the only way to consume them is to either have an entire Swift toolchain, or write your package parser. Compared to other platforms with json, yaml, or toml files, that's a huge lift

3

The kind of modularising solution I’m thinking of is like GitHub - pointfreeco/isowords: Open source game built in SwiftUI and the Composable Architecture. · GitHub. See how they add all their features into local packages? It seems like a Swift Packages can be used to modularise a production-ready codebase.

I did not know about Pods, but I just feel like Swift Packages should be talked about on its own, and SPM as something added on top of Packages due to a need for managing dependencies.

4

SwiftPM is called a package manager, but you can really think of it as more like a build system with dependency management capabilities.

e.g., it combines the conceptual role of things like "xcodebuild" and "CocoaPods" into a single coherent tool, if that analogy makes sense.

1 Like
5

That's part of it yes. Probably the biggest part. SwiftPM's does let you define a set of packages and manage dependencies between them. It lets you define information that's fed to the underlying build system so that it can build the necessary targets in those packages for the right platforms with the right build settings. But it also lets you launch executables and run tests in those packages. And it lets you publish packages to package registries.

I do know teams that are using SwiftPM just as a build system. And we're working on features, like multi-language support and external builders that will make that even more powerful. But I like to see it as the CLI front end to the Swift Package ecosystem that lets you build, test, deploy, and publish reusable packages. And if you're just looking for an easy way to build and run your local Swift project, it needs to be good at that too.

6

We were also talking in the build and packaging workgroup that we really need to revisit our documentation. I'm not sure it covers this topic well enough.