RFC: Deprecating generate-xcodeproj

My bad ignorance, I just realized that you can actually open Package.swift and it will open the Package in Xcode allowing you to work on the tests, samples, etc. so I'm now fine and do not need swift generate-xcodeproj.

I use generate-xcodeproj pretty often. My main project is Gryphon, which is a command-line tool, and developing it in Xcode involves at least three things:

  • Setting the "custom working directory" to be $SRCROOT so I can run it from the folder I'm using (instead of one of Xcode's random temporary build folders with a weird name);
  • Setting about ten arguments in "Arguments passed on launch" that I use often so I can turn them on and off during development;
  • Adding a "Run Script Build Phase" to run swiftlint.

Having to do all this every time I open Xcode to work on something would be pretty cumbersome, to say the least. I think the worst part would be adding the arguments: I never remember all of them, and I forget the way some of them are spelled and the options I'm supposed to give them.

If there's a way to save these settings without generate-xcodeproj then it's OK for me, otherwise it's a big -1.

1 Like

You can create a workspace and drag your package into there. then you have all the settings saved in the workspace file (which you can keep outside the package) and don't need an xcodeproj file.

Doesn't generate-xcodeproj wipe out all the settings every time you run it anyway? Opening the Package.swift directly gives you an Xcode workspace in .swiftpm you can check into Git and keep even when changing dependencies etc.

Build phases and scripts are definitely one of the big missing pieces for XPM and SwiftPM in general

1 Like

Please don't do this. At least until there is a way to pass arguments to Xcode when opening a Swift package.

For example, when working on OpenCombine, I usually open two Xcode windows — one with an Xcode project created with the command swift package generate-xcodeproj -Xswiftc -DOPENCOMBINE_COMPATIBILITY_TEST, and one with the package opened through Package.swift. This lets me run OpenCombine tests against Combine, while working on OpenCombine implementation.

If there was a way to pass the -DOPENCOMBINE_COMPATIBILITY_TEST argument to Xcode when opening Package.swift (or at least specify an .xcconfig file), I wouldn't complain.

1 Like

I realize this is an Xcode problem, but it is related.

Our team is in the process of switching most of our libraries from Xcode projects to SPM. However, as detailed in FB7724987, when a project importing these packages is set to gather code coverage from only some targets in Xcode, code coverage isn't actually gathered from them. It works for the same libraries, when they are imported as Xcode projects... so the only workaround we've come up with so far is to use generate-xcodeproj and then link these projects instead of the packages to get the code coverage.

I'd love for this to be fixed in Xcode, but I've pointed this out already during WWDC and it was said to be a known issue then... and supposedly under active investigation... no change since then.

So until this bug is fixed, I'd appreciate if this command continued to exist.

2 Likes

As described in another topic, you can use $ OPENCOMBINE_COMPATIBILITY_TEST=1 open Package.swift.
Although all packages opened by Xcode at the same time are affected by the environment variable in that way. :cry:

Although all packages opened by Xcode at the same time are affected by the environment variable in that way.

That is exactly what I don't want. I want to open the same package in different configurations in two Xcode windows at the same time.

I know how you feel.
I also think 'generate-xcodeproj' should not be deprecated until Xcode introduces new features handling such situations.


Note:
Swift Package Manager itself also adopts "Package.swift" switching dependencies by environment variables: https://github.com/apple/swift-package-manager/blob/4ab1f7c97dab7ae6aa01a4ce992ca76213a94a32/Package.swift#L296-L312

I used generate-xcodeproj because the "Find in project" allows me to search package dependency code as well. When I open Package.swift directly and use Xcode's native support, I can't use Xcode search to find code across all packages.

When I'm developing my Vapor app, for example, it is very useful to search around the Vapor packages for other uses of an API.

Does anyone have a solution for searching code including the packages? I would be very sad if this went away.

I used generate-xcodeproj because the "Find in project" allows me to search package dependency code as well. When I open Package.swift directly and use Xcode's native support, I can't use Xcode search to find code across all packages.

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.

1 Like

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.

You should have a Swift Package Dependencies section below the package:

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?

2 Likes

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.

7 Likes

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.

13 Likes

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:

  • Renaming, adding or removing files requires either reopening Xcode or clearing derived data.
  • Adding new files is a poor experience (you cannot name them, templates don't work).
  • There is no way to add the 'organisation' so the copyright, in file headers, does not get added. Additionally the framework is not added to the file headers. On this point I know I get used to the way these headers look but if we were looking to tidy them up for Packages (remove the copyright and other bits then I'd expect the headers to be tidied or removed from the Xcode file template).

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.

3 Likes

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)