Remove workspace, just use project.

[mbrandonw]

Thanks to a tip from @krzysztofzablocki we found out that we can get rid of the workspace if we hold the Xcode project in a sub-directory instead of the root, which we already do.

[stephencelis]

Nice.

[ZevEisenberg]

It looks like one file from the workspace (a Package.resolved) did not get deleted, so the workspace file is still there. 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?

[stephencelis]

It looks like one file from the workspace (a Package.resolved) did not get deleted, so the workspace file is still there.

Ah good catch, thanks! Pushed af583e4!

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 🤷

[ZevEisenberg]

Thanks for the info! I didn't know about these two things:

1. That Xcode will read the package as a folder reference when you close and reopen it.
2. I forgot that you'd need a top-level Package.swift for libraries.

Since this isn't a library, I'd still probably nest Package.swift, Sources, and Tests inside a Packages folder to get them out of the top level.

Oh, and the recent items thing doesn't bother me because I make Terminal shortcuts to open all my current projects directly. Niche, I know 😆

[gohanlon]

To maybe save a little time for anyone else wanting to reproduce this modification in their own isowords-structured project:

To add your root package to your Xcode Project, File → Add Packages… and press the Add Local… button. Select the root directory of your project (which contains your root-level Package.swift).

[stephencelis]

To maybe save a little time for anyone else wanting to reproduce this modification in their own isowords-structured project:

To add your root package to your Xcode Project, File → Add Packages… and press the Add Local… button. Select the root directory of your project (which contains your root-level Package.swift).

@gohanlon This unfortunately seems to have the same problem as dragging the root directory into the project :( It seems to work when you first do it, but when you close and reopen the project, the local package will no longer load correctly.

[gohanlon]

@gohanlon This unfortunately seems to have the same problem as dragging the root directory into the project :( It seems to work when you first do it, but when you close and reopen the project, the local package will no longer load correctly.

I should add that I'm using Xcode 13b3.

And, using the process I described, I'm not seeing that problem. The local package appears as I'd expect both when the project is reopened after closing and after restarting Xcode completely. I can build and run all my targets, clean and build, etc.

I also took care to make sure that my change the the .xcodeproj exactly matched the corresponding change to isowords. Could this be a bug that's fixed sometime between Xcode 12 and 13b3?