macOS Why is Xcode still so rubbish??

[Kingcoherent]

Just a grumble as I don't have any solutions, but perhaps by venting someone will jump in and tell me what I'm doing wrong.

I use Cursor or RustRover for most of my development. Cursor probably dominates now, especially since I've started to use Bevy for game development. It's clean and reliable and the agentic coding is fast and reliable (note: I have a Claude subscription but prefer to use agents from within an IDE).

After Apple added agentic coding to the new version of Xcode, and several OS and Xcode updates later (grr), I I thought I'd give Xcode a try again for a Mac app I wanted to build in Swift (unfortunately there's no alternative to Xcode for this).

Using Claude in Xcode and it keeps mangling my project, creating new files instead of updating old ones. This is a Claude <> Xcode integration problem. But when I tried to manually fix it, it just gets worse. In particular the .pbxproj way of organising files in parallel to the files system structure seems to result in confusion for the agent, but also confusion for me. It is infuriatingly idiotic and these choices make it extremely difficult to diagnose and fix problems (e.g. build phases referencing files that don't exist, or are in different locations, no ability to sort or copy the build phases list of files, the fact that the main way to edit this sort of thing is through a ****ing point and click UI rather than just editing a text file). That before I get to performance (memory/cpu) and stability.

Xcode has been crap for as long as I remember. Instead of fixing Xcode Apple seems to spend more effort shutting down viable alternatives. How do regular users cope? Stockholm syndrome?

 

[Kingcoherent]

And so unstable. My word. Please write software that doesn't crash so often Apple.

 

[keksikuningas]

I like debugging in Xcode but otherwise everything about the whole development experience for the apple ecosystem is often quite miserable. The project files, that aren't human readable and change constantly, the package system.

Stuff like sandboxing not being something you are aware of until you stumble upon it. All the trouble with linking dynamic libraries to your project.

For your last point, people who spent a long time developing for Macs and iOS etc are just not noticing these things anymore. I remember back in the day JetBrains used to offer a Obj-C / Swift IDE but they gave up on it somewhere in the late 10s iirc.

There are write-ups online about using Neovim as a Swift IDE for developing apps, it even comes with simulators and UI preview. Have you looked into that? Would go along nicely with using CLI agents

 

[Senor Cuete]

"rubbish" is a noun.

 

[Kingcoherent]

Thank you for adding to the discussion. https://dictionary.cambridge.org/dictionary/english/rubbish

UK informal. Rubbish very much used as an adjective (or even a verb).

"rubbish" is a noun.

 

[Kingcoherent]

I like debugging in Xcode but otherwise everything about the whole development experience for the apple ecosystem is often quite miserable. The project files, that aren't human readable and change constantly, the package system.

Stuff like sandboxing not being something you are aware of until you stumble upon it. All the trouble with linking dynamic libraries to your project.

For your last point, people who spent a long time developing for Macs and iOS etc are just not noticing these things anymore. I remember back in the day JetBrains used to offer a Obj-C / Swift IDE but they gave up on it somewhere in the late 10s iirc.

There are write-ups online about using Neovim as a Swift IDE for developing apps, it even comes with simulators and UI preview. Have you looked into that? Would go along nicely with using CLI agents

I will give neovim a try. My main problems with xcode seem to mostly stem from the opaque binary project file format. I used to have a team if iOS developers report to me when i ran both product and r&d teams. They were constantly complaining about the project files and had written utilities to safely, programmatically update them. Given i havent worked with them in years, and theyre also no longer at that company it’s probably ok for me to pick their brains on that.

 

[keksikuningas]

I will give neovim a try. My main problems with xcode seem to mostly stem from the opaque binary project file format. I used to have a team if iOS developers report to me when i ran both product and r&d teams. They were constantly complaining about the project files and had written utilities to safely, programmatically update them. Given i havent worked with them in years, and theyre also no longer at that company it’s probably ok for me to pick their brains on that.

there are tools that autogenerate and update these project files when you build a project so that these project files are consistent between devs and don't litter the version control with minor changes that would otherwise get constantly committed from having different signing keys for compiling or having personalized IDE settings

 

[!!!]

Using Claude in Xcode and it keeps mangling my project, creating new files instead of updating old ones. This is a Claude <> Xcode integration problem. But when I tried to manually fix it, it just gets worse. In particular the .pbxproj way of organising files in parallel to the files system structure seems to result in confusion for the agent, but also confusion for me. It is infuriatingly idiotic and these choices make it extremely difficult to diagnose and fix problems (e.g. build phases referencing files that don't exist, or are in different locations, no ability to sort or copy the build phases list of files, the fact that the main way to edit this sort of thing is through a ****ing point and click UI rather than just editing a text file). That before I get to performance (memory/cpu) and stability.

There's definitely issues with Xcode, but all of this sounds like problems resulting from your AI barfing up nonsense and you letting that barf get all over your project.

mostly stem from the opaque binary project file format

They're not binary, and they're not opaque. Maybe if you put down your word barfer you'd learn a thing or two. They're actually text files, which you (yes YOU) can read! You don't need someone's GPUs to pre-chew these files for you.

 

[casperes1996]

I will give neovim a try. My main problems with xcode seem to mostly stem from the opaque binary project file format. I used to have a team if iOS developers report to me when i ran both product and r&d teams. They were constantly complaining about the project files and had written utilities to safely, programmatically update them. Given i havent worked with them in years, and theyre also no longer at that company it’s probably ok for me to pick their brains on that.

Yep. Generating project files based on your file system and potentially a settings JSON file is the way to go. We have a custom tool for this at the company I work at (using the Ruby gem xcodeproj), but you can also achieve this with CMake and other tools.

On the general point of this thread, you can absolutely develop for Apple platforms without Xcode. You do not need an IDE. You can do it in nano if you want. I have a looooong list of complaints about Xcode; At the same time I think Xcode is the best IDE out there. Honestly though that's less praising Xcode and more condemning the world of IDEs.
Xcode is slow, prone to crashing and its project files are hell. It is still much much nicer to work with than fx. Android Studio/JetBrains, and that's my second favourite IDE.
I do quite like a simpler text editor setup like neovim, emacs or even VSCode.

 

[Kingcoherent]

I do most of my development in pure Rust, in Cursor (usually without agentic help). This is for programs that I compile for Mac targets. Bevy, for example, can target several platforms including MacOS and iOS. Fortunately this means I don't need to have anything to do with Xcode (except to update it every now and again when I have c/c++ dependencies). If I'm hacking together something quick in Python and/or web technologies then it's usually start in a Jupyter notebook or use Cursor or one of the Jetbrains IDEs.

Thanks for reminding me, it was the Ruby xcodeproj that the team had built on previously. I have a general aversion to overly complex build chains, it's a shame we either need to rely on CMake or Ruby to make this clean. Perhaps I've been spoilt by Cargo 🤷. If this continues to be a pain I will trial one of these approaches (or I'll just go back to writing pure rust).

Yep. Generating project files based on your file system and potentially a settings JSON file is the way to go. We have a custom tool for this at the company I work at (using the Ruby gem xcodeproj), but you can also achieve this with CMake and other tools.

On the general point of this thread, you can absolutely develop for Apple platforms without Xcode. You do not need an IDE. You can do it in nano if you want. I have a looooong list of complaints about Xcode; At the same time I think Xcode is the best IDE out there. Honestly though that's less praising Xcode and more condemning the world of IDEs.
Xcode is slow, prone to crashing and its project files are hell. It is still much much nicer to work with than fx. Android Studio/JetBrains, and that's my second favourite IDE.
I do quite like a simpler text editor setup like neovim, emacs or even VSCode.

 

[Kingcoherent]

There's definitely issues with Xcode, but all of this sounds like problems resulting from your AI barfing up nonsense and you letting that barf get all over your project.

They're not binary, and they're not opaque. Maybe if you put down your word barfer you'd learn a thing or two. They're actually text files, which you (yes YOU) can read! You don't need someone's GPUs to pre-chew these files for you.

Oh, it absolutely is a skill issue. I haven't had to use Xcode much for about five years and I'm (forgive the pun) a little rusty. Options have moved, UX behaviour is weirdly inconsistent and doesn't default to sensible behaviour etc. It brings back terrible flashbacks of having to use Delphi and C++Builder at one of my first professional jobs (from which you can probably infer my rough age). I'm proficient in several flavours of Assembler, C/C++, Rust, Java, Scala, Julia, R, Python, c#, f# and a bunch of web technologies. I would be the first to admit that I'm not that proficient in Swift and have forgotten/expunged most of my Objective-C knowledge. My last individual contributor role was as a research scientist developing among other things... language models (or as you so eloquently put it: word barfers 😂). Almost a decade in management/exec level means I'm only just getting back to being properly hands on again.

I have managed to use Cursor to build quick Swift prototypes recently. It's a bit of a pain but does actually work reasonably well (it is able to write effective up to date Swift, but it cannot actually add new files to projects/ edit the project files so except for changing existing files a lot of its instructions are "make this change manually"). Given that I usually set the underlying model used by Cursor to be Claude, I had expected Apple's own coding intelligence to give a far better user experience but same code quality - same model but properly integrated with Xcode. I guess it just has a very long way to go.

FWIW - I have helped several companies operationalise AI agents in a very productive manner. Given proper guidance (guardrails/rules, specs etc) they can be exceptionally effective. I would still do a lot of high performant code manually, and determine the architecture myself. However, for prototyping they absolutely can be used to great effect; given that most organisations have problems working out what to build (in a specific enough manner to actually deliver), rather than have engineering capacity issues, I do absolutely recommend exploring how they can be used in your workflow. Also, had you asked me this 18 months ago I was a huge sceptic and would have said that the tech is nowhere near ready.

 

[casperes1996]

Just to add; you can do swift and objective c without an Xcode project file and Xcode. Can’t make use of Xcodebuild but you can use swiftc and clang to compile your source files without needing to add anything to a project file. The project file and xcodebuild is a convenience as it can manage all of the build phases and linking together into an app bundle but that can also be manually done or done with a makefile. You can even have make targets that spawn a simulator install the app on it and runs with —console. Using Xcode as your build system is optional

 

[Kingcoherent]

Thanks. I will probably look to do this. The debugger is just about the only good thing about Xcode, but it really isn't worth the pain of the rest of Xcode.

The Code Intelligence feature is utterly half baked and nowhere near the sort of quality I expect from Apple (although, given the mess that is Tahoe and Liquid Glass perhaps there are serious problems with quality control in Apple's software division). Even in a completely fresh project it's getting confused, thinking it has applied changes when it hasn't. It claims to be reading files from disk and claims that Xcode itself is using cached copies. It makes absolutely no sense for xcode to have several layers of broken file caching: if you want to offer a wysiwyg code editor, then for goodness sake the code you see on screen should be the code on disk. I'm going to assume this is a problem restricted to the Claude agent integration. Cursor can work on the same codebase without issues (it just cannot add files to projects or manage the build phases). Frustrating few hours - but as I tell juniors, the highs of programming aren't possible without the lows.

 

[casperes1996]

Thanks. I will probably look to do this. The debugger is just about the only good thing about Xcode, but it really isn't worth the pain of the rest of Xcode.

So if you're not using Xcode, you can use
xcrun simctl launch booted --wait-for-debugger <bundle-identifier>

It still requires Xcode installation of course as it's part of the command line tools that come with it but it can work outside of an Xcode-IDE context.
Then the command will print a pid that you can attach to with lldb and boom. You've got lldb attached to the simulator's app process outside of Xcode. And from launch. Set your breakpoints with b, run with c when you're ready; Works great.

You can replace "booted" with a simulator ID if you for example have more than one simulator booted at any given time or whatnot.

 

[Kingcoherent]

Update for anyone interested.

Been using agent assistance in Xcode for a day and a half now and have a couple more observations:

- I'm hitting rate limits very quickly. While cursor summarises the current conversation when it gets too long, Xcode does not. I regularly hit "prompt too long" if the conversation goes on too long. This problem is compounded as it then results in rate limits in Claude itself (forcing a three hour wait for a reset).
- the first wouldn't be such a problem if Xcode didn't regularly fail to apply the updates suggested by Claude to code. I prefer to always review the change, rather then just let the agent loose on the code base. When I apply change from the agent conversation it isn't guaranteed to actually save the change to disk. There are a couple of problems here, firstly the Claude code agent doesn't seem to know that changes that have not been applied may not be ready in the file to build upon. One possible solution would be for the agent to stop and wait for review before moving to the next planned change. The other, much worse change, is that the Xcode UI is hopelessly buggy and inconsistent. Sometimes it behaves as one would expect, and when the change is applied a "proposed" tag is removed and the change visually looks to be applied. However, other times the "proposed" tag is missing. When applied the option to apply is replaced bye a copy snippet button; however, this cannot be taken as evidence that the change has been applied to disk. I have found that it's best to keep kith desktop open in the background and manually check the diffs to see what has been added.

I've managed to build a fairly complex application in two evening's work. It does task tracking for me, with voice control to add tasks (thanks to the very cool AppIntents framework, which mostly works well - Apple massively favours its own apps so the voice command is often incorrectly routed to the wrong application ending up in Apple's todo app or the journal app even when I use a "prefix" specific to my own application). I've used Apple Intelligence to hook into a language model to help me break down tasks, provide estimates, map out inter subtask dependencies and plan each day given task priorities and due dates (and review each day at the end to help understand why some tasks weren't done). I've used SwiftData (with iCloud backup). It's an elegant api and has let me do some fairly sophisticated reporting and add calendar, reports and a Gantt view. Are there apps out there that already do this? Probably, but not with the workflow that I want.

Would this have been quicker to build manually? Probably not for me given how out of practice my swift is and that I have not yet read all the documentation for Apple Intelligence and AppIntents. I guess full time I could have got here in 8-12 days.

Would this have been possible for someone to do with even less knowledge? Almost certainly not, when the agent messes up it really helps to have a good understanding of what the likely root cause is. Similar to a junior dev, it will often very confidently state it knows what's wrong and then make an even bigger mess by going own a rabbit hole. However, if guided it will very quickly fix problems in the correct way.

We're certainly in an exciting time to be a software engineer. And I mean software engineer, not coder. AI may be able to write the code (80% of the time), but it doesn't enforce good engineering practice. The user of the tool needs to do that.

 

[Kingcoherent]

Upgraded the Claude agent in Xcode and now it's a mess. The agent keeps forgetting to consult Agents.md. With cursor we can use cursor rules to enforce sensible practice. CLI Claude seems to need a CLAUDE.md to reference the Agents.md. I can work around this so long as I remember to tell the agent to read in the Agents.md at the start of every conversation. From Claude:

Xcode's limitation:
• Xcode gives me access to files you're viewing or that I explicitly search for
• There's no equivalent to .cursorrules or CLAUDE.md that gets auto-loaded
• I have to manually search for project guidelines

What would help in Xcode:
Since Xcode doesn't have a built-in convention, the best approach is:
• Keep Agents.md􀰓 (which you have ✅)
• When starting significant work, I should proactively search for it
• You can remind me if I forget (like you did)

You're right that this is an Xcode limitation - it doesn't have the same agent configuration mechanisms that Cursor or the CLI have. Apple would need to add support for something like auto-loaded project guidelines files.

The more frustrating issue is that there seems to be significant context bleed from one chat session to another and following this update Xcode <> Claude integration really struggles to create files in the right place. Claude is adamant that the problem is Xcode not providing the correct interface. An attempt to create a file in /docs/specs/ (usually) just prepends "docsspecs" to the filename and stores it in the wrong place, usually the project repo root. This would be annoying on its own, but sometimes it _will_ create files in subfolders, but using paths from other conversations?!

The user experience of agentic coding in Xcode feels like the very first agentic coding, which was (quite frankly) a waste of time. But these are not issues with the model's ability to write correct code, it's entirely down to a terrible implementation by Apple and what appears to be close to no quality control for the Xcode product.