> Claude Code integration in Xcode would be very cool indeed, but I might still stick with VSCode for pure coding.

I'm sticking with VSCode too, but it's a bit silly to suggest that anyone is using XCode because it's their preferred IDE. It's just the one that's necessary for any non-trivial Apple platform development.

Adding a code generator isn't a marketing ploy to get people to switch editors, it's just a small concession to the many hapless souls stuck dealing with Apple on the professional side, or masochistically building mac SwiftUI apps just to remind themselves what pain feels like.

▲

wahnfrieden 3 days ago | parent | next [-]

I actually continue to use Xcode (in vim mode now that they have that) purely because of the way tabs work… in Vim and Xcode I’m able to have the same file open across multiple tabs and window-tabs, allowing me to arrange sets of files for particular tasks. But in VS Code it sends me to another window when I want to view a file next to another one, just because it’s already open elsewhere. I can’t stand this behavior as it slows me down and breaks my ability to see the files I want to see next to each other without many extra steps to rearrange things over and over. A ticket requesting this behavior change has been open for years with no progress.

▲

brailsafe 3 days ago | parent [-]

That's an interesting auper apecific detail that I think I've encountered once or twice. I'm reminded of one niche reason I also chose XCode for non-apple stuff, which was to print code on paper. I don't remember why I struggled to do it in VSCode at the time, but XCode was the solution.

	▲	wahnfrieden 3 days ago \| parent [-]
		I typically have 5-6+ panes open per window tab representing an area of work. In Xcode I can also make new window tabs that inherit the same set of tabs/splits/panes allowing me to "fork" and tweak a view of files. I use these features continuously throughout the day and hit jarring blocks trying to work this way every session in VS Code which makes it impossible to have more than one arrangement at once. I've been using this workflow for 15+ years in Vim before Xcode.

▲

manmal 4 days ago | parent | prev [-]

I mean you can stay in VSCode for most activities if you hate Xcode that much (I can relate btw). Plugins like Sweetpad make this possible. My approach now is to develop all logic in small Swift packages and run swift test in VSCode (or Claude Code), so I only absolutely need Xcode for debugging and building releases. Every once in a while I try SwiftUI previews, but those are usually broken anyways.

	▲	brailsafe 3 days ago \| parent [-]
		Ya I was considering a similar workflow last time I was steeped in SwiftUI. I don't dislike it that much actually, maybe just how slow the compile and error alerting is/was last time. I mainly found mac SwiftUI performance to be lacking, along with the transparency and documentation of the api. Swift itself is fine, and I give a xcode a lot of credit for somehow functioning as well as it does with so much accumulated functionality/complexity/bloat. SwiftUI previews were... manageable but not great.