Swift Package Manager Series 05｜Third-party Package access and management in iOS projects

When talking about third-party dependency management on such issues, the focus is more forward:

• Can this library be accessed through SPM?
• Can Xcode recognize it?
• How to write the version number

Of course these are important, but in real projects, the real cost is often several years after it is installed.

Because once third-party dependencies enter the project, it will bring about a whole series of long-term problems:

• How to control the upgrade rhythm
• Which modules will be affected by API changes?
• Whether the specific library is directly exposed to the business code
• Once you want to replace the library, will the cost be high?

So the real difficulty in “managing third-party packages” is governance.

1. Before accepting third-party dependencies, the first thing to ask is “Will it enter the core boundary?”

Before a library is added to a project, the first thing I usually ask is not:

• How many stars are there?
• Is the document beautiful?

Instead:

• Will it go directly into a lot of business code?
• Will it define some kind of interface shape for us in the future?
• How much impact will it have once it is upgraded or replaced?

Because some libraries only have peripheral capabilities, such as debugging tools, logging backends, and one-time gadgets; Some libraries will directly enter the core of the system, such as the network layer, image layer, routing layer, and storage layer.

Once the latter is selected incorrectly, subsequent modification costs will be very high.

So I am more concerned about whether it enters the “edge layer” or the “backbone layer”.

2. Don’t let the business code directly know too many details of the third-party library

This is the most easily overlooked, but the most critical piece of experience.

Assume that an image loading library is used, and its API is everywhere in the project:

• View layer directly imports
• ViewModel also knows its type
• The tool layer also depends on it

Then this library will soon change from “dependency” to “part of the infrastructure”. If you want to upgrade or replace it in the future, the cost will be far higher than expected.

So a more stable approach is usually:

• Wrap your own abstraction around appropriate boundaries
• Let the business rely on the capability interface rather than the library itself

This does not mean that any third-party library must be fully packaged, but at least for those dependencies that go deep into the main trunk layer, isolation should be seriously considered.

3. SPM makes access easier, but it can also easily make “adding a dependency” too frivolous.

This is a very real side effect.

Because SPM access is so easy, many teams will slowly develop this habit:

• Saw a small need
• Search a library
• add in
• It’s just one package anyway

It is very efficient in the short term, but long-term problems will gradually accumulate:

• Dependency expansion
• The compilation chain becomes longer
• Some libraries have not been maintained for a long time
• Multiple library functions overlap
• There are many dependencies in the project that “no one can explain the reason for existence”

Therefore, SPM makes dependency management lighter, but lightness does not mean that governance standards should be relaxed. The lighter the tool, the more human control is required.

4. The core of version management lies in whether the upgrade strategy is clear

When I first learned this content about the SPM version, I would first pay attention to:

• Exact version
• scope version
• upToNextMajor

These rules need to be known, but the more important engineering questions are actually:

• Who is responsible for upgrading this dependency?
• How often to review versions
• Should the upgrade follow business needs or be managed regularly?
• How to quickly assess the impact when an upgrade fails

If no one is responsible for these things, then no matter how beautifully written the version constraint is, it will only become a “fixed value that has not been changed in several years”.

So relying on version management is essentially a governance rhythm issue.

5. The most fearful thing about third-party dependence is “no one will look at it after entering the system”

Everyone was very serious about many dependencies on the day they were introduced, but no one took care of them after that. This brings several typical risks:

• Security updates are lagging behind for a long time
• API change backlog explodes into an upgrade
• No one in the team knows who else relies on this library
• Similar ability libraries are continuously superimposed

Then the project will slowly enter a state:

• Dependencies are not unusable
• But no one dares to move

This is more common and harder to deal with than “choosing the wrong library in the first place”.

6. What I value more is whether the dependency list is “explainable”

A healthy project dependency list is not necessarily short, but preferably explainable.

In other words, when picking up a dependency, the team can clearly state:

• What problem does it solve?
• is it
• On which floor it is located
• Whether there are isolation borders
• If it needs to be replaced in the future, what will be the main cost?

If a dependency has become:

• “It’s been there before”
• “It seems to be used somewhere”
• “Delete it for fear of something happening”

Then it has actually entered a governance out-of-control zone.

7. A practical strategy: treat third-party dependencies in layers

I usually divide dependencies into three categories:

1. Marginal dependency

For example, some development aids, log reporting, and low-frequency tools. Even if this type of dependence is used more directly, the risks are relatively controllable.

2. Platform dependency

For example, pictures, network, storage, routing, etc. This type of dependency is likely to enter the system trunk, and the exposure scope should be carefully controlled.

3. Deeply coupled dependencies with weak replaceability

Once some libraries are connected, they will affect a large number of API designs. This kind of dependence requires clear boundaries at the beginning, otherwise the replacement cost will be very high in the future.

This layered approach is more realistic than “all use it directly” or “one layer is all included”.

8. Conclusion: The core of third-party Package is long-term governance

To put it in shorter form, I would say:

When managing third-party packages in an iOS project, what really matters is “after it enters the system, can you control its boundaries, upgrade rhythm, and replacement costs?”

So dependency management is a long-term governance capability.