Swift Package Manager Series 01｜The positioning and importance of SPM

The first time many iOS developers really come into contact with Swift Package Manager is often because they “want to connect a third-party library.” It is easy to draw an overly narrow conclusion:

Isn’t SPM just a replacement for CocoaPods?

This conclusion is only partially correct.

SPM can certainly install dependencies, but if you only understand it as a dependency manager, you will underestimate what it really changes. What it is changing is actually how Swift projects define modules, how they organize dependencies, and how they establish project boundaries.

So in this article I want to make a premise clear first: **The value of SPM is not just “getting the code more conveniently”, but “organizing the code more standardly”. **

1. SPM is first of all Swift’s official module system entrance, not just a downloader.

The core value of many tools comes from the ecology, and the core value of some tools comes from “whether it is an official path.”

SPM is closer to the latter.

Its importance stems first from three facts:

• It is Swift’s officially supported package management and modularization solution
• It is integrated with the evolution direction of the compiler, tool chain, and Xcode
• It not only manages third-party code, but also naturally supports managing your own code

These three points taken together mean that it is gradually becoming the default language for Swift engineering organizations.

This is not a change of the same magnitude as “one more command to install dependencies”.

2. What it really encounters is the “boundary” problem

What is really difficult to manage in a mature project is always the following issues:

• Which code should be separated into modules
• Which capabilities should be directly depended on by the host project?
• Which modules can reference each other and which ones should not be referenced
• Where is the boundary between public capabilities and business capabilities?

Once SPM enters the project, these issues become more specific. Because it is no longer just “dividing directories into folders”, but actually defining:

• What is the public interface of a module?
• Which modules it depends on
• Who relies on it
• How it should be tested

Therefore, I say that the core of SPM is to force us to think more seriously about module boundaries.

Reasons for increased importance

Many small projects can survive well with “one App target + a bunch of groups” at the beginning. But as soon as the project reaches medium scale, problems will begin to appear:

• Compilation speed is getting slower and slower
• Public capabilities and business code are mixed together
• Module dependency direction is not controlled
• A change will trigger the recompilation of a large amount of irrelevant code
• Difficult to tell which code is truly reusable

At this time, you will find that the problem is “the project boundary does not exist”.

SPM is becoming more and more important because it provides a more standard path than “continue piling directories in the main project”. It allows module boundaries to change from a convention to a real engineering structure.

4. The biggest difference between SPM and the dependence tools of the old era is not just the experience, but the role positioning

In the past, it was common to have simple expectations for dependency management tools:

• Help me install the third-party library
• Help me with versions and integrations

But SPM will soon take it to another level: It not only manages “libraries written by others”, but is also very suitable for managing “modules taken out by oneself”.

This change is very critical. Because once you start organizing your code into Packages, the role of SPM changes from “installer” to “module system”.

At this time, the issues of concern are no longer just:

• Can it be installed?

Instead:

• How to define module interface
• How to hide internal implementation
• How to keep dependencies one-way
• Which modules deserve independent testing

This is where engineering maturity starts to increase.

5. Many teams will reach SPM sooner or later

On the surface it looks like it’s “updated”, but in reality it’s closer to how modern Swift projects are organized.

As long as a team starts doing these things seriously, it will naturally get closer to SPM:

• Want to do a clearer module split
• Want to extract public capabilities
• Want to reduce overexpansion of the main project
• Want to make dependencies explicit
• Want to make module testing more natural

In other words, in the process of pursuing engineering boundaries, many teams finally found that SPM is the most convenient way to carry out tasks.

6. But its value is not in “it becomes advanced when used”, but in “the boundaries can finally be defined seriously”

Another misunderstanding should be avoided here: When the topic of SPM is mentioned, it is easy to equate it with “modular mature team”.

This is actually not accurate.

SPM by itself does not automatically lead to good structure. If you haven’t thought clearly about it in the first place:

• Why does this module exist?
• What it exposes and what it doesn’t
• What is its relationship with the host project?

That just moved the original mess from the main project directory to the Package directory.

Therefore, the value of SPM does not lie in “making it modern”, but in that it makes many boundary issues that could have been vague in the past finally no longer able to be vague.

7. It won’t automatically solve anything

This is also important. SPM does not automatically help resolve:

• Is the module dismantling reasonable?
• Is the naming clear?
• Dependence on whether the direction is healthy
• Is a certain public module drawn too early?
• Are the business layer and the basic layer mixed together?

That said, SPM is not an architect, it’s just a tool better suited to hosting a good architecture.

If the team has no boundary awareness to begin with, SPM may end up just packaging the problem in a more “modern” way.

8. Conclusion: SPM is becoming more and more important. On the surface, it seems that it can install libraries, but in fact it is closer to it and is more suitable for hosting modular projects.

To put it in shorter form, I would say:

The reason why SPM is becoming more and more important is that on the surface it seems that it finally allows us to install one less CocoaPods. In fact, it is closer to making it easier for Swift projects to turn module boundaries, dependencies and project structures into explicit designs.

So what’s really important is never just “dependency management”, but:

• Modular
• Standardization
• Make boundaries explicit

This is why it increasingly deserves to be taken seriously.