Package dependencies added from Xcode not showing up in Package.swift file

I would expect to see listed within the my package's Package.swift file all dependencies to other pacakges I add using Xcode but it is not the case.

Is there an extra step I am missing to have my Package.swift file synched?

Thanks!

They aren’t the same thing.

You can have either a Swift package or an Xcode project as a top‐level entity, but not both. (However, you can add things as dependencies of a Swift package, and have an Xcode project depend on that local package.)

I think @Victor_Guerra is referring to Xcode’s integration with SPM. The fact that it offers no tooling around working with the package file, much less automatically adding dependencies as you’d expect, is just another point that shows the SPM support perfunctory. It’s unfortunate that after so long, this is all we get for a year.

I know that.

However, if you open a package in Xcode, “Add Package Dependency...” is greyed out, because Xcode cannot do that at all. It can only do that for Xcode projects.

(Asking the Xcode developers to enable it for packages too and have it do something useful—as you say—would make perfect sense.)

However, Victor wrote this:

That implies he successfully clicked on “Add Package Dependency...” and it did something.

From that, I suspect he is mistaken and isn’t actually adding the dependencies to a package. He must have something else open (too?) that he is adding dependencies to, and that is why they are not appearing in the manifest—they are actually dependencies of something else.

I think he just expected the obvious behavior: that projects using SPM through Xcode maintain a package file. It’s unfortunate that Xcode just maintains it in parallel. Additionally, not properly supporting packages when it defaults to opening them in a directory with project and workspace files, is additionally confusing.

But that’s the thing, even if they live in the same directory, the package and the Xcode project are two separate things. If you have a package and a project within an Xcode workspace, then the package might be a dependency of the Xcode project, but the two should not be seen as equal to each other:

  • You can have a dependency of the Xcode project that is not a dependency of the package. For this, you enter it in Xcode’s user interface, because it tracks such dependencies in its own opaque way in hidden in an .xcodeproj bundle like it does everything else about the project (a practice I am not defending).

  • You can have a dependency of the package that is not a dependency of the Xcode project. For this, you enter it in the package manifest. (But if the package is itself a dependency of the project, the project will inherit such dependencies transitively.)

Xcode should not synchronize the two dependency lists, because they are different things.


I just experimented, and if you have two projects and a package in the same workspace, you can click “Add Package Dependency...”. The first thing it does is ask which thing to add the dependency to. It gives you the two projects as options, but not the package since it doesn’t support doing that (yet?).

Presumably it skips this step when there is only one viable thing to attach the dependency to. If you instead have a workspace with one project and two packages, it doesn’t ask and instead selects the only thing possible—the project—without showing the panel. While that makes a certain sort of sense, I can see how it obscures what you are actually asking it to do. It feels more like you would be adding it to the whole workspace even though that is not the case.

That illusion would be much compounded if the workspace consisted of exactly one package and one project that were being merely used as two ways of vending more‐or‐less the same thing. Despite the actual presence of three separate entities—a workspace, a project and a package—you could feel like you are only working with only one entity, and you might expect all ways of looking at it to have the same information and the same dependencies. But that does not reflect the actual design, which allows for any number of interrelated components.


Additionally, not properly supporting packages when it defaults to opening them in a directory with project and workspace files, is additionally confusing.

There is no project involved. When you double‐click Package.swift, it creates a transient workspace containing only the package. That is why the interface won’t let you do project‐related things to it like add configurations, localizations or build settings. There is no project to store them in.

1 Like