Question about project structure

[jchitel]

Hello!

I recently discovered your project and have decided to restructure my app similar to yours. I haven't had any issues replicating the structure, I just had a question about rationale.

Is there a reason that you have the swift package at the root level and the xcode project embedded in the App/ folder? I found it a bit unintuitive to set it up this way, because the app is the actual product, and the swift package just contains the code used by the app. Additionally, someone cloning the project would most likely try to open the swift package in xcode rather than the xcodeproj, which is what is actually needed.

Is there any issue with putting the xcode project at the root level and having the swift package embedded within? Even better would be to have them both living at the same level, but I'm not sure if there is some technical issue with setting things up that way.

[igor1309]

The most important benefit for my team is that xcodeproj merge conflicts are now a thing of the past.

[andreyz]

If you choose to subscribe to PointFree episodes, there's an extensive explanation and much more in https://www.pointfree.co/collections/tours/isowords/ep142-a-tour-of-isowords-part-1

[jchitel]

I watched the link that @andreyz provided (here, very informative btw!) and was able to deduce what I wanted to know.

It seems that the initial project structure had an Xcode workspace containing both the app project and the swift package. The swift package still lived at the root, and the app project still lived in the App/ folder. I like this structure because the workspace lives at the root and is more obvious for new developers. However, this workspace does not currently exist in the repo, so I had to track it down in the commit history to figure out why they changed it.

The workspace was removed in #122, which provided pretty much exactly what I was looking for:

Also, you should be able to pull the Xcode project into the top level folder if you want, which has the advantage of making xed . just work. Wasn't sure if you preferred doing development from a top-level Package.swift, though?

This unfortunately doesn't work ☹️. A top-level project file and package can't seem to currently coexist peacefully in Xcode. We've tried some incantations and none seem to work:

• Drag Package.swift into the Xcode project: it brings it in as a source file, not a package
• Drag the top-level directory into the project: it's a package! However, when you close and reopen the project file, it's a folder reference, not a package

(xed . also will open a directory's package first, even if a project file—or workspace—exists in the same directory.)

Seems that the best options are:

• Top-level project file with nested package. This works if you don't ever need to depend on the package elsewhere via git (which is technically the case here), but for libraries like the Composable Architecture this is not an option
• Top-level package with a nested project. (What we did here.)
• Workspace solution we had previously. This was not great because Xcode would always exclude the workspace from recent items 🤷

It would seem that the reason they want the swift package at the root is so that it can be referenced by other repos via SPM. This is not a concern for my use case because no other projects at my company will need to depend on that code, but it can certainly be restructured later if that is needed for some reason.

Of the three options suggested here, I like 1 (top-level project with nested package) and 3 (workspace). I think I would prefer 1 for my case because it emphasizes the app as the primary product, and it would require minimal changes from my current project structure.