Swift Package Manager Series 06｜Applicable scenarios and limitations of SPM

Once a consensus is reached in the technical community, another problem easily arises: Everyone began to default to “since the direction is right, then we should go all out as soon as possible.”

It’s easy for SPM to fall into this rhythm as well.

It is indeed a very important tool for modern Swift projects, but “important” does not mean “should be fully promoted immediately at all times.” Just because the tools are advanced, it does not mean that the current project already has the boundaries and organizational conditions to undertake it.

So I never really like that kind of general conclusion:

• “It’s time to move everything to SPM”
• “If you don’t use SPM, you will fall behind.”

A more practical question should be:

Whether the project is currently suitable for migrating certain capabilities to SPM, and whether it will be more stable after the migration is completed.

1. The prerequisite for being suitable for SPM is that the boundaries have begun to be clear.

If a project is currently in this state:

• All code is highly coupled in one App target
• Pages, services, routing, and configurations can penetrate each other
• The boundaries between public capabilities and business capabilities are confusing

If you rush to SPM at this time, you will probably just move the existing coupling intact into multiple packages.

It looks modular on the surface, but in fact the dependencies are harder to understand and more painful to change.

So the order I prefer is:

1. Let the boundaries become clear first
2. Reuse SPM to host these boundaries

Rather than the other way around, expect SPM to automatically help create boundaries.

2. When is the best time to start using SPM?

I generally consider the following signals that a project is ready to introduce or expand SPM:

• There are clear public capability modules that can be independent
• The team has begun to have a sense of boundaries, instead of just dividing code by directory
• Certain capabilities deserve independent testing and independent evolution
• The main project has incurred significant maintenance costs due to expansion
• The team is willing to bear additional design costs for module boundaries

If these conditions emerge gradually, SPM often becomes a natural next step.

3. When is it not appropriate to “force yourself on”?

“Strengthening” here refers to advancing SPM as a political mission.

I would be very cautious in the following situations:

1. The project is still very small, and the main pain point is not module boundaries at all.

If the current project only has a few people, is small in scale, and has relatively simple boundaries, the main problem may not be modular at all.

Introducing a bunch of Packages too early at this time may bring greater complexity than benefits.

2. The team has no basic consensus on boundaries.

If you are connected now:

• How to distinguish the basic layer and business layer
• How to distinguish the page layer and service layer
• How to distinguish public modules and host modules

If there is no consensus yet, SPM will only expose these disputes in advance, but it may not resolve them.

3. Just to “look advanced”

This is the most dangerous type of motivation. If the reason for adopting SPM is just:

• Everyone else is using it
• The architecture diagram will look better
• More modern look on resume

There is a high probability that it will eventually become “upgraded form, unchanged structure”.

4. The most easily overestimated aspect of SPM: thinking that it will automatically bring about a good architecture

It won’t.

The strengths of SPM are:

• Hosting module boundaries
• Explicit dependencies
• Make module evolution more natural

But it won’t answer for the team:

• Which module deserves to exist
• How to design depending on the direction
• Is the public floor drawn too early?
• Should certain business codes not be independent in the first place?

That said, SPM is more like a good foundation than an architect. Without design awareness, a complex structure will still be built even if the foundation is replaced.

5. Migration strategy is more important than “should you migrate or not?”

Many projects have failed due to “too drastic changes in law”.

A more stable migration strategy is usually:

• Start piloting the modules with the clearest boundaries first
• Do a small number of high-certainty splits first
• Run several iterations to verify dependencies and collaboration costs
• Decide whether to continue to expand

Instead of just coming up:

• Full warehouse unpacking
• All public code is forced into Package
• Migrate all third-party dependencies at once

Modularization is a long-term project and is not suitable for one-step advancement.

6. A practical judgment criterion: after using SPM, will the project be clearer or more convoluted?

If a change is made after migration:

• Dependency direction is clearer -Module responsibilities are clearer
• It is easier to judge the scope of impact during review
• Test boundaries are more natural

Then this migration is most likely worth it.

If after the migration is completed:

• There are more modules but the responsibilities are not clearer
• The host project still knows a bunch of internal implementations
• Changing a function requires jumping back and forth across multiple packages

That means the problem isn’t the tool, but the boundary design itself.

7. Conclusion: SPM is worth using, but not worth using as a formalist migration

To put it in shorter form, I would say:

When to use SPM, the key is not “whether it is the right direction”, but “whether the project and team are currently ready to use module boundaries to carry complexity.”

So the really stable approach is:

• Use it at the right time
• Start with appropriate boundaries
• Used to carry structures that have been clearly thought out

In this way, SPM will become a burden reduction tool rather than a new round of engineering burden.