Symlink to SPM Package no longer builds in Xcode 12.5 (was ok on 12.4 & earlier)

Hi. SPM packages referenced as local folders in Xcode (as opposed to repository URL) are no longer parsed and built in Xcode 12.5 when those folders are symlinks. This used to work in Xcode 12.4 and earlier versions.

File system:

    MySwiftPackage (symlink to another location, like ../MySwiftPackage)

where the Xcode workspace references the local symlink like this (MyWorkspace.xcworkspace/contents.xcworkspacedata):

  location = "group:MySwiftPackage">

no longer works. The package no longer appears as a package within Xcode (icon is like a terminal-stamped file), and it's not built anymore.

My colleague Benoit filed a feedback with that a couple months ago: FB9007750

We use symlinks to more rationally organize shared code in the file system. So my question is: is this feature temporarily broken, or is it the new normal of SPM in Xcode?

Thank you.

1 Like

Not sure about packages as symlinks but we had plain folders which also do not work. Since Xcode 12.5 symlinks appear just like some regular files compared to the previous behavior from 12.4. I also filed a bug report a while ago.


Thanks for the detailed description and the test workspace in the bug report. That definitely does not sound intentional to me — that sounds like a bug in Xcode's file reference resolution. I notice also that if you open the file inspector when the symlink is selected, the type shows as "Default - symbolic link" so it seems as if it's not getting resolved to the path that contains a package.

I suspect this has to do with the symlink itself and isn't specific to packages. I've made sure the bug report is on the right team to investigate it.

1 Like

Here is my related bug report: FB9051612

It also references another Xcode symbolic link & SPM related issue: (reported as SPM issue, but it was identified as an Xcode issue)

The latter issue is critical to our project and requires a semi-workable hack in our package manifest to hard switch between paths of the active target or all sorts of IDE tooling will be broken and we don't get any syntax highlighting, code completion, etc.

thank you, appreciated.

sounds similar indeed. I refrained from using hard links for folders, as this sounds like a fragile workaround (+ a mess on the file system).

We migrated our plain Xcode project over to SPM. Compared to the normal project SPM does not allow overlapping sources or in other words multiple targets referencing the same root source. In our case that's exactly what we needed, at least until we figured out how to refactor our huge code base and get rid of all defines. That said, our code base merges multiple targets and uses defines to produce different results. This is possible to replicate in SPM by creating multiple targets and applying custom defines and it also compiles as expected. However only Xcode cannot properly resolve the related symbolic links, which are used to overcome the overlapping root source code path.

In fact, such solution was suggested in this post here:

Note that the targets with overlapping sources are final application products, not libraries, which is why it should be totally fine allowing their source code to overlap. However they are still marked as libraries so that we can reach their entry point from a single file in the actual Xcode project to jumpstart the final application.

Terms of Service

Privacy Policy

Cookie Policy