In Xcode you can drag the checked out dependencies into a workspace and then they act like local dependencies
Thanks,
After googling I finally figured out that I need to drag the folder from Finder to XCode to have it working.
After some research I understood that for the local dependencies XCode keeps the references to the local paths. Because we build projects via CI/CDs, this would raise us a concern that such changes might be commited accidently, and it will cause our builds to fail.
And we use R.swift in our Swift packages, which helps us to enforce compile-time check of resources. Currently 'R.swift' parses xcodeproj and extracts all resource URLs for the current target during build. In order for this tool to function with XCode integration, I reckon it would be possible to modify it, if there were a way to provide to the tool all resource URLs.
The references to the dependencies are stored in the workspace not the package repo (I believe) so if that's not in the same directory then it should be fine (and will probably cause problems if it's in the same directory).
As for R.swift you'll need to raise an issue on their repo for supporting SwiftPM if generate xcode-proj is deprecated
We have many private SPM packages that each have their own suite of tests, which run when pull-requests are opened against that package. This works by using post-clone.sh CI scripts that generate the Xcode project which is then built and tests are ran.
We use BuddyBuild and now testing Apple's Xcode Cloud CI and neither have support for integrating with SPM packages on macOS. To be able to run tests or create build artefacts for SPM packages on CI we have to generate an Xcode project in order for the CI to detect targets etc.
While Xcode can open SPM packages for development I don't believe this is true for automation workflows.
1 Like
If a CI system doesn't natively support packages, creating a simple wrapping workspace with a reference to the package typically works.
You can use this kind of workaround for Xcode Cloud as well.
Interesting didn’t know that was possible will give that a go.
On my end I haven't been able to use SwiftSyntax to run unit tests unless I generate the Xcode project with this command and open it manually (this has been reported here)
I use this in my SwiftInspector repository. I've tried a couple of approaches but all of them require some pretty hacky approaches. I'd love to understand if there's an approach I'm missing here.
1 Like
Answering the original theme of this topic, I would be disappointed to see this removed because it would be another sign of Xcode moving in the wrong direction about project configurability.
I realised this was deprecated because I was creating a new iOS app and I wanted to do so by creating a Package.swift and then to generate the app from that, because I want all my configuration to be easily readable and code reviewable (which .xcodeproj isn't).
In my opinion, the path the Dev Tools team should be on is more towards supporting things like what XcodeGen and Tuist provide; not continuing to bury stuff deep inside Xcode's UI (and inside Xcode's project format). These tools are great and they're not just useful for large apps, they're also great for bootstrapping small projects.
Ideally, one day an app's whole configuration could live inside a human readable swift file, and that's what I thought the end goal was. Deprecating this command makes me believe that will likely never happen.
2 Likes
Removing support for generating an Xcode project and moving more project configuration in a Package.swift are not exclusive, IMO they're actually completely related. Removing the generate-xcodeproj flag would eventually mean (I'm assuming of course as this is all guess work and my opinion) that SwiftPM would add support for specifying platforms and targets and other things that you can do in an Xcode project. E.g. the extensible build tools pitch would plug some of the gaps for pre and post build scripts in Xcode etc.
Removing this is not Xcode moving in the opposite direction to project configuration being human readable - it's enabling SwiftPM to move in the right direction.
3 Likes
I obviously can't talk about the future here, but the way I think about deprecating generate-xcodeproj is that it means we have moved away from needing to generate a proprietary file format to Xcode natively understanding a human-readable and documented file format.
10 Likes
As much as I hate Xcode project files, until there is a way to run build script phases in a standalone swift package, I don’t think removing this feature is a good idea.
1 Like
As someone said that generate-xcodeproj might be feature of xcodebuild, because when you create xcodeproj file you need to use xcodebuild.
A few drawbacks of removing this feature:
-
swift testcan't provide-destinationflag, which means you must write#if !os(macOS)flag across all code if your project iOS specific. That is really disappointing when you create file - you must to write this boilerplate. - In Package.swift you can't provide specific build settings like optimizations
- You can't create your own configuration across all your private deps, for example UnitTests configuration
xcodebuild can run tests from "pure" SwiftPM projects that have only Package.swift in them and don't have .xcodeproj. You don't need to generate the latter to run tests on iOS for a SwiftPM package.
1 Like
@Max_Desiatov Yes, you're right. Thank you, I didn't know that. But still some fastlane plugins doesn't work without workspace or xcodeproj. For example using of xcov plugin requires existing of project file. Though it's problem of fastlane.
I'm surprised nobody mentioned xcproject and workspace features like e.g. remembering:
- order of files within a folder if they were manually reordered
- misc. source code settings such as file type, syntax highlighting type if set to different from default, indentation settings
- pre-build and post-build scripts (this one can be potentially added to SPM eventually, I presume?)
Sorry, can't live without those things 
!
I wanted to bump this up again and say I'm frustrated and stuck between the two worlds now: .xcodeproj and the Package.swift-based projects.
Many projects especially in the server space don't work very well with the generated xcodeproj, so clearly there's no going back, esp. that the feature will be deprecated soon.
On the other hand, the new Xcode project management is still lacking a few important features such as reordering of files in the Navigator.
I don't know about the others but I usually organize my projects by layers (as in, architectural layers) and order them accordingly. If I need to go e.g. one level down relative to where I am I know where to look in the Navigator straight away. The alphabetic ordering of folders and the files in it which is the default, adds a mental tax for me and slows me down considerably.
(And I was wrong about syntax highlighting in the previous post, Xcode does remember it.)
Is this a lot to ask? - To at least allow reordering of files and make it persistent?
1 Like
I'd disagree that file ordering should be part of the manifest, it doesn't make sense in my mind. Instead it should be configurable by an editor, whether that be Xcode or VSCode etc.
The main reason for deprecating the --generate-xcodeproj is that at it's core, Swift packages are cross platform. Having stuff that's specific to Xcode doesn't make sense when you can pick that package up and build it on Windows or Linux (or even the command line with swift build).
3 Likes
Tim, I didn't say file ordering should be part of the manifest, although at least ordering of modules might be preserved by the IDE, actually.
What I meant was ordering of folders and files in Xcode's Navigator. Xcode could remember these things in its silently generated workspace file in principle, although this information obviously won't be available in other environments.
I don't know if there's any reasonable solution to this, but alphabetic ordering of things in the Navigator is unintuitive and can literally hinder productivity especially in large projects.
1 Like