Is there a way to disable the generation of a .xcworkspace file and generate and open only the .xcodeproj file?
Hey 
No, there’s currently no such option. Is there a specific reason for why you want an .xcodeproj only?
Hey! Thanks for your swift response!
I don’t need it because everything will be in the project itself, especially if you only use SwiftPM.
Of course, it’s not a big deal, but I expected that the Workspace won’t be created with only the Project.swift file itself (without the Workspace. swift). I guess the workspace is probably there so the project can be modularized further with multiple projects, but that’s optional for some of us devs and we will probably never need a workspace.
Thanks for sharing the motivation @vburojevic. I can’t think of a technical limitation that would prevent us from enabling something like this, other than potentially having cascading effects that assume the presence of a workspace. From my end, I’m onboard with turning it onto an actionable item. Thoughts @marekfort / @core ?
By the way, welcome @vburojevic to the community, and thanks for posting your request here :). It’s highly appreciated.
1 Like
The generation process does assume the existence of a workspace. We’d need to do a spike to see how complex it would be to get rid of those assumptions.
That being said, I’m not sure if it’s worth the effort to cope with some projects having .xcodeproj and some both .xcodeproj + .xcworkspace when the impact on the DX is basically zero. Both should be gitignored … so, what’s the point?
I think before we turn this into an actionable item, somebody should do a spike to see what it would take, so we can discuss if the additional complexity is worth the very marginal improvement.
I agree, in any case, this should be low-priority. @vburojevic Would you be interested in doing a spike to assess the cost of implementing and maintaining this? You might find these guidelines useful for that. If the outcome of it is that the ongoing maintenance is not high and that there are no side effects that could be in conflict with other developments, we can turn it into an actionable item for any contributor to work on it.
I’ll try to find some time this month to have a look. 