As a Swift developer, I’m excited by the Swift Package Manager’s potential to help tame the complexity of our software projects by making them highly modular.
Compared to how modularisation in Swift was achieved before SPM (e.g. creating targets in Xcode to split code into static libraries or dynamic frameworks and having to memorise various build setting incantations) the lightweight approach of SPM is a breath of fresh air. Using the old approach before SPM, I used to think twice wether it was worth the effort and the overhead to do it, and probably more often than not would decide to skip it and remain with a huge monolithic code base with no modularisation at all.
It reminds me of how branching in source control management used to be before and after the introduction of Git. Before Git, branching used to be such a pain that it was rarely used. Git made it so easy that one could easily branch and merge many times a day if required. It looks like SPM is about to do the same thing for breaking large Swift code bases into many small modules.
Xcode 11 introduced a robust integration with SPM that makes it a joy to create and work with Swift packages (along with some understandable growing pains which will probably be addressed in forthcoming versions). This feels like a huge step towards making easy micro modules a reality.
When creating a new package, either in Xcode or using the `swift package init` command line, an initial module named like the package is created along with an initial test target for that module. That makes it very easy to start working on the package right away without any configuration hassle.
When trying to create additional modules in that new package however, we’re faced with a sequence of required manual steps, which are both tedious and error-prone. First we have to add a target declaration to the package manifest and probably a depending test target as well. Then we might need to add that target to the library product targets declaration. We will then have to create subfolders under Sources or Tests, named exactly after the targets, and we’ll have to create at least one source file in each of these new folders. These are all stringy typed elements. Forgetting a step or having a typo anywhere will render the package invalid in a way that is cumbersome to debug.
This was the trigger that led to the development of the Modules utility. It grew out of a personal need to overcome the hurdles on the way to a smooth module-rich workflow. The initial version (currently available on the Mac App Store) is focused on two things:
Eliminate the need to perform the manual steps described above.
Provide a visual representation of the dependency graph to help reason about the code base in a more intuitive way.
If you’re a Swift developer keen on making the most out of SPM, I believe you’ll find great value in using Modules alongside Xcode or any other editor or IDE you use for Swift development.
If you’re already using Modules, let us know what you think through modules-app@spectrum-reflections.com. Any kind of constructive feedback is welcome. We already have some ideas on which directions we’d like the application to evolve, but first and foremost we’d like to hear what’s important to you, the user.
Finally, a note on a minor inconvenience in the first version: since I insisted on writing this app 100% in SwiftUI (the single exception to that being NSDocument which is imported from AppKit), when you double click a target name or choose “Rename…” from the context menu, the target name field activates but does not auto select the current text. This requires another double click to highlight the text before you can start typing. Expect an update with a fix soon.