You can change your search scope to search through all packages in the project. On the Find Navigator press
New Scope..and select location "Project". There is no need to generate xcodeproj for all the Vapor packages.
Project doesn't seem to be an option for me. I can only select Package, which searches my Server package, but none of the dependency packages.
It was showing Project for me as I had an iOS xcodeproj open. If you choose Package it should also work.
Problems that Xcode can't resolve at this point are:
"Package.swift" cannot be opened in different environment variables simultaneously. (Ref.)
Xcode ignores "~/Library/Developer/Xcode/Templates/File Templates" when the package is opened by "SOME_ENV=1 open Package.swift". (Ref.)
Any other problems?
Again, I think 'generate-xcodeproj' should not be deprecated until these problems are resolved.
By the way, does Xcode team know this discussion?
Until a Package manifest has feature parity with an xcodeproj, I'm opposed to this change. Multiple times I've started building packages (whether for work or myself) and have reached a point where I can no longer proceed as a package.
At that point, it's great to be able to generate-xcodeproj to shift to a more powerful project format and keep going. Losing generate-xcodeproj would be a major feature loss of a fallback option, because Package.swift just isn't powerful enough yet.
So... please don't do this yet.
I wrote on this thread back in November about how I felt about losing this feature. I still think it is a great feature.
However, over the last couple of months, I've changed my mind, the reason being that Swift is a multi-platform language. Other than when working on Apple platforms, this feature provides little or no value at all. Given that Swift usage in non-apple platforms is growing, we should consider keeping the tooling as simple as possible.
While this is probably out of the realm of the Swift Package Manager maintainers, I feel the feature for generating Xcode projects should be implemented by Xcode itself. This is where the feature truly belongs, in my opinion. Open a package, save as project.
I've submitted #FB8971650 with a request for adding this feature to Xcode.
I've switched a number of my projects to Swift Packages and I feel it's a little early to be deprecating this feature.
Xcode is not good enough at the moment for working directly with Packages. Please correct me if there are solutions to these issues but I am finding:
Not to mention some of the issues with adding scripts that others have mentioned. But I can understand and support the plan to remove this with SPM and Swift becoming platform agnostic.
One thing I'd really like to see improved is building xcframeworks from just the package manifest. GitHub - unsignedapps/swift-create-xcframework: A simple Command Line Tool to create XCFrameworks by wrapping xcodebuild. and other commonly used tools rely on the generate-xcodeproj command to then run the usual archive commands. It's the only reason I've ever needed to use that command personally.
I have neither of these issues with Swift package support in Xcode, if anything it's far superior, especially for newcomers. Vapor used to recommend closing the Xcode project, adding Swift files via Terminal and regenerating the project anytime you wanted to add/remove source files and change your manifest. This can all be done inside Xcode without any major issues (my only gripe being the package resolution process running any time you add/rename a file for a couple of seconds)
I realise this is an old thread, but I'd like to raise a use case that Package.swift still doesn't handle which is compiler flags. A particularly important current case for this is setting compiler flags to enable the new concurrency features (and presumably other new features in the future will use similar flags). There doesn't seem to be any way to build/debug swift code with compiler flags in Xcode without an Xcode project. I guess one could build an Xcode project by hand using the old build system and/or a Makefile to achieve the same result, but this would be unfortunate. I wonder if compiler flag support (either transient support in Xcode's Package.swift handling, or a way to encode them in Package.swift itself) should be a pre-requisite to removing generate-xcodeproj.
I think this might help: SwiftSetting.unsafeFlags(_:_:)
You can use it like this in the package manifest to enable the concurrency feature:
...
let package = Package(
...
targets: [
.target(
...
swiftSettings: [
.unsafeFlags(["-Xfrontend", "-enable-experimental-concurrency"])
]
),
...
],
...
)
Oh, thank you! Somehow I didn't see that 
Does anyone know the way to sign an app without .xcproject? I decided to try generate-xcodeproj with an .xcconfig file, but faced this deprecation warning...
For now deployment target is macOS, but I'd like to find a way to avoid using .xcproject for any app. I know about tuist for example, but I'd prefer spm-only approach.
The main blocker I have to switching to consistently using XCode's SPM's integration over generate-xcodeproj that the former fails to resolves dependencies that require at least some forms of authentication; I have not got it to work with github dependencies that are private or internal company (Amazon) dependencies. SPM through the CLI has no issues with these.
This reason alone means that very few of the packages I work on can use XCode's SPM integration particularly easily (where it "just works" as you would expect) - any service that depends on the client of another internal service or shared business logic that has been abstracted into a library runs into this issue.
iirc there are two way to deal with this. you can have Xcode use SwiftPM underlying git subsystem which makes that aspect identical to the CLI experience, or you can configure Xcode SCM accounts so Xcode underlying git subsystem does the right thing. cc @NeoNacho and @abertelrud
Right, there is defaults write com.apple.dt.Xcode IDEPackageSupportUseBuiltinSCM 1 to use the SwiftPM Git subsystem.
Alternatively, this describes how to configure SCM accounts in Xcode.
Now xcode starts to warn generate-xcodeproj. Can the swift package proxy be set separately?
https://github.com/vapor/fluent-sqlite-driver.git: An unknown error occurred. curl error: Recv failure: Operation timed out (-1)
But directly using the swift package always reports an error, always.
It is interesting how to do it and take advantage of existing solutions to check for issues (danger) and process code coverage as well as integrate code formatting/linting tools. The most reliable way to integrate it all was (with some side effects like having coverage data counted for classes you do not own, for example).
I suspect and HOPE that WWDC and Xcode 13 will not only remove this deprecated feature but replace it with a great versatile take on this.
Apple’s tools work great for Apple, they work great for consultants and small teams, but if you work in bigger companies and need to adapt to their processes and requirements you need to layer a lot of extra and some hacky tools/steps to do so and I would really appreciate if we felt more included too.
Thanks @NeoNacho, that makes the SPM integration much much more useful to my team. I have updated our documentation with this configuration.
Is there any situations when we wouldn't want XCode configured like this?
Dear Swift Development Team,
I like the new improvements for Swift packages, they're great.
Correct me if I'm wrong, but in XCode it's impossible or at least not straightforward to edit Swift Packages directly.
To solve this problem I created a 'wrapper' for Swift Package Manager, which relies on 'generate-xcodeproj' command. I use this tool for many of my projects and it makes convenient to use 'swift package edit' command. This provides the ability to commit changes via command line.
Just in case here is the source code for my tool: