I've seen a few complaints 😈 related to symlinks in Xcode dotted around the internet, but nothing put things into perspective as much as me trying to use symlinks in Xcode, myself.
A small price to pay to avoid having to mess with symlinks which cause their own issues in Xcode - Joe Susnick
The package no longer appears as a package within Xcode (icon is like a terminal-stamped file), and it's not built anymore. - Raphael Sebbe
this might be why:
TLDR: Xcode gets very confused by symlinks, and if you're not convinced, I suggest you play around with symlinks in Xcode. For those who understand how to use Xcode with symlinks, its a pain to clean and rebuild (losing incremental builds) and a small bit of mental overhead to ensure you check you're editing a hardlink. For someone joining your project, its a booby trap. May Tim Cook help you 😅.
I wanted to share code/ files between modules (targets) in a Swift Package, a question I posted on the Swift forums, and Swift doesn't compile if it detects 2 files being shared across 2 targets. Fortunately:
I think you can trick SwiftPM using symlinks. - Jeremy David Giesbrechts
Though I was able to use symlinks in Xcode, Xcode did not treat me very well, with the problems I listed in this page. The other alternative is to save the shared file in module, and share that module between the modules that want to use it.
You want to move your header files into the
include/ in preparation for Swift Package Manager support for your Objective-C library. I recommend moving the files into the
include/ directory, instead of creating symlinks, to avoid the issues listed above. If you're looking for a great Swift Package to model your project structure on, look at SGDCornerstone.
hard links cannot be represented in git - Stack Overflow's Jakub Narębski
That should be enough. 😅
PS: I used Xcode 13 beta.