Hello, swift community!
I would like to discuss an issue that i experienced when using local SPM packages, but first of all I would like to start from my setup
We have a monorepo for several of our projects that share a lot of commonly used logic such as UI elements, design system, resources, permissions logic etc
At some point we decided to organise everything inside workspace but quickly discovered that different projects require different remote packages with sometimes different versions so we moved from workspace to several Xcode projects
We share this common logic inside spm packages to ease our integration of frameworks
But when I try to open two Xcode projects or project and package that both depend on same local package at the same time I always get an error:
Couldn't load a xcode project because it is already opened from another project or workspace
Or
Missing package product
It really frustrates because I have to use VSCode or some kind of external IDE to lookup code inside another project.
What kind of solution can you suggest for me to solve my problem?
Same problem here. Just begun learning server Swift. I went with 3 core projects:
project-server - executable package.
project-client - Xcode project.
project-api - library package with shared sources for sever and client.
project-api is added to both server and client as a local package since it is naturally being developed with server and client. Now I can't have both client and server projects opened in Xcode.
The problem you are describing is exactly what drove Apple to develop Xcode workspaces.
However, as you have stated, your project architecture seems to preclude using a workspace. But, it seems to me that your architecture is being driven by the requirements for the remote packages you are using. Have you considered updating your code so that it all depends on the same version of the remote packages? Using the same external package version would seem to allow you to simplify your architecture and keep you from fighting with Xcode to do something it really wasn't designed to do. If you do the analysis, weighing the costs of maintaining the dependencies and subsequent program architecture against the cost of upgrading the project, you might find it favorable to upgrade in the long-run.
However, since I don't know the specifics of your use case, you can take all of this with a grain of salt.
Well, in times where there are a small number of projects it usually works kinda well, but as project count and dependencies count increases Xcode on our developer machines starts to struggle in indexing and fetching dependencies.
Also For SPM its kinda a requirement to fetch everything and lock the build before it resolves everything even if I don't use it.
That's why we moved into separate projects.
Also when you work for example in mono repo of javascript projects you don't actually need to fetch every package that you need)