I used to worry that generate-xcodeproj
would be dropped before the native package support was capable of everything I needed, as there were originally a handful of problems. However, all but one have since been solved. I haven’t used generate-xcodeproj
in my main workflow for months now and my opinion has reversed. I now find it annoying that users expect a package to be compatible with generate-xcodeproj
, since it isn’t capable of everything and ends up restricting the features a package can use. For example, XCTest can be used on iOS from a raw package, but if you generate an Xcode project, it will fail to compile. Conditional dependencies were never possible in a generate project either. (I apologize if either of those facts changed in an update without my noticing.) See this post for the fragile hack I am currently applying to differentiate the two build modes for a number of packages.
The one thing I still occasionally use generate-xcodebuild
for is to temporarily create a project I can add a run‐script phase to, so that I can see the errors and warnings of external static analysis tools displayed inline by Xcode. There is no way to attach such a script phase to a package, and no other way I know of to get Xcode to parse the output and highlight the offending lines. If there are only a few issues flagged, locating them manually from the line numbers in the terminal output is tolerable. But when I apply a new tool and there are hundreds of warnings, it is much nicer have them funnelled and tabulated into Xcode’s interface, after which each one takes only a single click to navigate to.
A month or two ago, I realized I was a bit of an idiot for not noticing that an Xcode project doesn’t actually have to correspond to the package at all if its only purpose it is to highlight source files. So I may as well just generate an empty one with only the script instead of going through generate-xcodeproj
and adding to the result. I will probably have completely switched over to this long before the next version of Swift comes out, so it isn’t a reason to stall deprecation of generate-xcodeproj
. Instead I mention it because it seems like something you shouldn’t have to generate a separate project in order to do. Xcode could maybe detect scripts checked in at .swiftpm/xcode/dev-scripts
and provide them as isolated schemes available to easily run? Some sort of feature to that effect would be nice.