I'm in the process of converting a fairly large cocoapod project to a swift SPM project, and my general experience with XCode + SPM in the past weeks makes me wonder : is this combination really used in the wild ?
Beside having Xcode (latest version) <-> swift integration crash very often (in addition to Xcode itself crashing), i've now realized how horrible SPM integration in Xcode is. Having a project with lots of local swift packages is a barely usable experience. Relative path in dependencies aren't recognized or diagnozed, SPM cache is often not up-to-date after a change (and my go-to solution so far is to simply kill and restart Xcode), etc.
Which made me wonder if people are still using this combination, or if people moved to VSCode or something else (and only keep using Xcode when no other choice is possible).
Xcode and SPM have been relatively stable for me – I'd be surprised if the majority of Xcode users aren't using SPM by now.
Yes, if there's some moving/renaming of modules that can put things in an inconsistent state – but as you say – a reboot of Xcode sorts it. Or, more typically just a 'clean', and wait for things to re-index. Generally though, once I've made whatever changes I wish to make to my project structure and Xcode finally catches up, it remains stable.
Welcome to the wonderful world of Apple‘s developer tools. They‘re obviously not eating their own dogfood. With the dance of regularly removing derived data, updating package caches, shuffling dependencies around it‘s bearable, but it‘s definitely not great.
Alas, there is no other choice for Apple platforms.
again, i would recommend giving the VSCode plugin another try (even if you’ve tried it before), it really has made huge strides (thanks to @adam-fowler !) in the past few months. and i have to emphasize this is a really recent phenomenon, if you tried it back around christmas-time and gave up on it because it was crashing every few minutes that is no longer happening.
Personally I use vscode/nvim/helix (mostly nvim but moving to helix) along with my tool swift-bundler to make macOS apps without xcodeprojs. I gave up on xcodeprojs a long time ago and life is so much more enjoyable. Unfortunately there are still things that xcode is required for such as publishing to the app store, but I'm slowly trying to implement everything needed to make an Apple platform app with swift-bundler and minimal Xcode usage. I've also got iOS support working in a private version which I'm hoping to publish soon (when I get the time to polish it up). I hope to also add Linux support soon so that a cross-platform app can be a single swift package without any proprietary xcodeproj nonsense.
I will admit, Xcode's debugging tools (especially the metal debugger) are better than anything else out there, so I open Xcode (and/or Instruments) occasionally to debug things.
I've run into issues when the package is open in Xcode along with a project depending on that package. Closing Xcode and opening only the package or the project seems to work OK ... until I forget. This week's Accidental Tech Podcast mentioned this same issue, so I know it is not just me!
I agree that Xcode in the Objective-C days was much better. Honestly, I think many of the stability issues we have in the present are caused by poor Swift tooling. The lack of IDE features, such as real plugins or more comprehensive refactoring options, are entirely the Xcode dev team's fault.
I would love to provide feedback, but i'm not really familiar with the intricate details of XCode / Swift tooling integration. I wouldn't know for example if a given issue while coding in Xcode is due to Xcode, to Swift language server, or to the bridging between the two (and I've given up a long time ago filing Radar to apple developpers)
So first I wanted to make sure i wasn't just using a subpar IDE for developing in Swift. Reading the comments here, it seems a lot of people are looking for alternate solutions to Xcode. I guess i'll give VSCode another try and see if the experience is better.
It’s fine to file feedback without that knowledge. That’s engineering’s job to figure out, perhaps by asking for more information.
This is unfortunate, because it’s quite literally the only way to guarantee someone at Apple sees your report. I understand the frustration at not getting a response, but it is much harder to influence the development process without an official bug report.
I understand your point and generally agree. However, in that particular case, i feel like either developers at Apple are using the same tool, and so they pretty much experience the same pain (and i assume they're working on it), or they're not in which case there's really no point in submitting anything, because the crux of the problem is elsewhere.
Tools have the same combinatoric complexity as languages. Often when something isn’t working it’s because of some unexpected interaction or a difference in configuration that’s throwing the tool for a loop. So yes, it’s very helpful to get bug reports with accurate reproduction steps, and the existence of bugs doesn’t mean the developers don’t use the tools at all.