Posted by davidbarker 4 hours ago
Xcode being loaded on my computer causes something akin to a kernel panic.
Not the fun kind where you get to read a backtrace and feel something. The existential kind.
Every time it hijacks a .json or .xml file association, I experience a rage that hasn't been matched since the Emacs/vi wars ... and at least those were about editors that could open in under a geological epoch.
I just want to look at a text file with pretty print.
I do not need a 12GB IDE to render curly braces. cat has been doing this since 1971. Dennis Ritchie solved this.
Why, Apple, in 40 years, could you not ship a lightweight dev-oriented text viewer? You had NeXTSTEP. You had the DNA of the most elegant Unix workstation ever built.
And you gave us... this behemoth? An app whose launch time rivals a full Gentoo stage 1 install ( see: https://niden.net/post/gentoo-stage-1-installation )
TextEdit is not the answer.
I've used Xcode for native iOS development and honestly, once you get past the Stockholm Syndrome phase, it's just fine.
- The interface is learnable.
- The debugger mostly works.
But the load times -- on every high-end MBP I've ever owned -- suggest that somewhere deep in the Xcode binary, there's a sleep(rand()) that someone committed in 2006 and no one has had the courage to git blame.
FWIW, I fear someone here tells me I've been missing a launch flag. Alas, it's my truth and I can't hold it in anymore.
As far as Apple providing anything, why are they the expected ones providing it? There are a gigabazillionumpteen text editors that can reformat JSON. I have Xcode, and have associated JSON with a different editor. Not once has it ever changed on me.
I believe that “Get Info”->”Open With”->”Change All…” still works, and there are command line methods or third party tools.
This has driven me to madness too.
I know the procedure.
The issue is that Xcode updates and macOS updates tend to reset those associations back. There's a long-running Apple Community thread titled literally "Stop hijacking file extensions with xcode" ( https://discussions.apple.com/thread/253702137?sortBy=rank ) and another I saw recently where a user documents their .md associations reverting after closing their laptop lid.
It's not universal, but it's not delusion either.
The deeper annoyance is extensionless files and edge cases -- log files, build artifacts, random output from scripts ... where there's no clean association to override.
Those fall through to whatever macOS thinks is clever, which is often Xcode.
As for "why should Apple provide it" -- because the company was founded by a guy named Steve who believed that details and care matter. Someone who said how the insides of a computer looks is as important as the outside and nagged his partner until the circuits looked right in their home-brew project.
Also yes, fair point, I should just fix it and stop complaining.
I failed at that today. Please forgive me.
To set file association stuff more easily than with the Finder GUI, you can run (with https://github.com/moretension/duti):
duti -s com.apple.textedit public.${whatever} all
You're being too kind. It feels like a 8 cores worth of parallel busy loops to me!
I bet Alan Dye insisted they put it in there so users can pause their busy to gaze at and appreciate his artistically minimal unpainted Liquid Glass window frame.
I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points. They are definitely fixing bugs. I make software for iOS, macOS, car play, and apple watch.
Sure sometimes I've got to reset or clear a cache, but this has never stopped my day.
What is so horrible about XCode?
This means you've learned to work around its shortcomings. A decade ago I used to develop in PyCharm for websites, and Visual Studio .Net for desktop apps. Then I had to learn XCode for a mobile app.
It was a surreal experience, like going back ten years in UX, while at the same time dealing with a myriad of modern but artificial limitations and breaking changes that meant the app needed frequent housekeeping even when its features remained unchanged.
For a company that gets a huge part of its revenue on its oversized App Store tax, developers, and their tooling, should be one of their highest priorities IMO. Instead, we get Kafkaesque situations like "my app doesn't compile today... oh, I need to open my Apple Developer account in the browser and accept a new little change in their kilometric EULA that I always pretend I've read carefully". Things like this could be handled better.
Edit: I also had to learn Android Studio for another app, and the experience had less friction overall, but that could mean that I've also learned to work around the shortcomings of JetBrains IDEs. Google is undeniably more developer-friendly than Apple IMO, though.
There is no perfect IDE. They all have problems / are inadequate / get in the way. I absolutely loathe IntelliJ IDEA for example, and think Eclipse is needlessly complex (though I'd like their code-indentation/formatting UI to replace the one in Xcode).
Honestly, Xcode gets a lot of bad comments, but it works pretty well for me and the debugging tools are pretty much top-notch if you take the time to learn them.
I started a project on January 5th. Running sloc right now I see:
---------- Result ------------
Physical : 44454
Source : 31019
Comment : 7284
Single-line comment : 2622
Block comment : 4662
Mixed : 210
Empty block comment : 2
Empty : 6363
To Do : 0
----------------------------
That's a lot of code in just under a month (and none of it from AI tools), I don't think the IDE is getting in my way.
Perhaps it's just the setup you (the generic "you") are used to or something. I've got 3 4k screens connected to a Mac Studio here, and plenty of space for a terminal or four to be running on-screen at the same time and in windows that don't obscure the things I want to look at. I guess if you code on an MBP and space is limited, it might be easier to switch to ? But I generally want that space for my debugger and console-app i/o. I think it'd just get in the way...
Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.
Sometimes I'll use Ghostty at the same time and switch between the two. Just depends on what I'm trying to do at the moment.
Nothing wrong with maintaining all the context you need in a single window instead of alt+tabbing to different apps, especially for those not engulfed by three 4K displays.
I expect others do things differently for different reasons as much as much as I expect an IDE to support more than one type of user.
> Because I like to get project-aware completions, or run pre-configured tools from the IDE in an actual shell, for example. > Also, when working on multiple projects, it’s much easier to have shells attached to a specific project that I can toggle with a keyboard shortcut to get process output or Claude right next to the code I’m looking at.
Window switching is bad enough on MacOS, especially if you have multiple projects open at the same time.
First, the performance is just bad. The responsiveness compared to apps like VSC or Panic’s Nova is night-and-day.
The attention given to the design of new features is piss-poor. Placing the AI functionality on the left sidebar makes no sense; all the other tools on the left are project management; the "let me run weird functions and interact with stuff" UIs like terminal, debug and logs are in the bottom panel. Or maybe a new tab in the main workspace area?
The SwiftUI preview canvas can't be floated as a separate window, making it all but useless on anything smaller than a 16" MBP (and only barely usable there). In fact, I think it might be impossible to use Xcode in multiple screens altogether…?
Old simulator versions and cache files hang around forever, you need a third-party app like DevCleaner just to keep your storage from filling with nonsense. Cryptic messages like "copying symbols to device"… clear-cache that doesn't seem to clear-cache, that stupid list UI for info.plist…
I never thought I'd have anything nice to say about PNPM package management, but you can always just delete `node_modules` and reinstall and count on things working. Swift package management is a cryptic mess, and their insistence on using a GUI instead of a basic JSON manifest just compounds it. Like the info.plist thing, a lot of Xcode is based on a developer UI philosophy from the Mac Classic days that has mostly been abandoned by the rest of the world.
Mostly, I think the vitriol surrounding Xcode is that Apple seems to think they're doing a good job; meanwhile their most ardent and adept users are insisting that they are not. Same boat as MacOS, really.
Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI? This problem seems to go back to the ancient times, but it gets worse and worse the bloatier macOS UI processes become (e.g. the more system frameworks they load at start).
The debugger variable view panel is so bare bones that it looks like it's ripped out straight from an 80's home computer monitor program.
When debug-stepping, the debugger frontend is quite often stuck for 10s of seconds at completely unpredictable places waiting for the debugger to respond (it feels like a timeout).
Step-debugging in general feels sluggish even compared to VSCode with lldb.
For comparison, VS2026 isn't exactly a lightweight IDE either, but debugging sessions start instantly, debug-stepping is immediate, and the CPU debugger is much more feature rich than Xcode's. While in Xcode, everything feels like it's been added as a checklist item, but then never actually used by the Xcode team (I do wonder what they're using to develop Xcode, I doubt that they are dogfooding their own work).
The one good and useful thing about Xcode is the Metal debugger though.
XCode is just terrible compared to Visual Studio.
As you said, there are weird beachballs all the time both while stepping and while waiting for the application to stop at a breakpoint (in cases where it happens instantly running under VS on Windows).
The Jump to Definition seems to have gotten flakier. Or maybe it's always been terrible relative to Visual Studio, IDK. But regardless a lot of times I'm just going by memory and Cmd+F on XCode - Jump to Definition and Cmd+Shift+o are just not getting there.
The Variables pane in the Debugger often just fails to actually ... display anything for any of the variables when stopped at a breakpoint. Sometimes it will appear after stepping a couple lines, sometimes it won't.
The Debugger is even flakier than usual when Lambdas are involved.
I am an emacs guy so it's not like I'm disposed to like Visual Studio. Visual Studio's quality has slipped a little too. But XCode feels straight-up amateurish in comparison to it. That said, at least Apple is actually exposing the capabilities of the IDE to their LLM integration offering. This is an improvement over the abortion that is Copilot integration in Visual Studio.
You can’t step into a lambda stored in a std::function
Absolute nightmare if you don’t know which lambda it might be so you can set a breakpoint in it.
Honestly, compared to Visual Studio, Xcode is 20 years behind.
Apple internally has structured their projects to not run into all of the debugger performance cliffs, but don’t provide any guidance on how to do the same thing and don’t proactively fix the problems they’ve avoided.
Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree.
- Interface Builder is stuck in early 2010s. Not only is the property panel missing half of options we now take for granted everywhere else (like corner radius), it also randomly won't read fonts in the current project, will crash the entire IDE if you Cmd-Z a big change (things like unembedding a view) and half the UI is still not rendered the way it will be on the phone. Yes, Swift UI exists, but most bigger apps are still XIBs and Storyboards and it's going to remain that way for quite some time.
- Autocomplete is a hit or miss. Very much like the mid-90s Microsoft IDEs where you'd get totally useless results until you've typed the whole line out already. It can be done well, look at AppCode.
- Syntax highlighting feels pretty much the same. Randomly flashes on and off, often doesn't highlight until return is pressed, takes a long time to load on large files etc.
- Git integration is by far the worst I've seen out of any IDE and I've seen many. I'd go as far as to say that SourceSafe integration in VB6 was done better. Just the whole layout, modal-on-modal returning to the first modal on an error in the second and so on. It's crashed when rebasing a few times too, I don't trust it with larger operations since.
- Documentation browser is this annoying little window with semi-useful search. But don't worry, the docs in there are useless anyways. I could go on and on about their approach to docs but maybe next time.
Don't even get me started on performance. Things like switching file tabs should be instant by now but there are still noticeable delays for larger files and IB screens. Plus there's now two kinds of tabs (app-level and file-level) to add to the mess.
It sounds like OP doesn't like the way Xcode does things differently to other IDE's.
But I agree that Xcode runs fine on small projects and recent version feel stable compare to past releases.
It most certainly is not, lol. That's the hype that the parent was referring to. Most people have found AI to be a detriment, not a benefit, to their work.
No, it isn’t. There are irresponsible voices in the community who claim that it is, but they always find convenient ways to omit the downsides (on both the tech and effects on society as a whole).
Single files in our codebase already blow the Copilot query token limit.
Great, Anthropic taught Claude to grep. On our project, it's still useless because it can't use the semantic search in the IDE.
This tells more about your code quality that about copilot, and I'm not a fan of copilot
Sure, it's a dumpster fire. But human engineers work on it just fine without investing man-decades into refactoring it into some shrine to the software engineer's craft.
The whole point of AI, in our parent company's eyes, is for no one to mention "code quality" as something impeding the delivery of features, yesterday, ever.
Not doing so while senior management demands the use of AI augmentation seems odd.
I think the bigger issue is contributing to OSS for putting Linux on a Macbook for example could be considered leaking company secrets since you would have access to internals. I find it hard to believe that Apple would go after someone for making a open source calculator app.
Ask Microsoft, they have much more experience with that.
> Did you think that SwiftUI was shoved down your throat?
On a scale of 1 to 10, it has been shoved down our throats at level 1 or maybe 2. Thankfully it's optional.
> Did you think that CoreData was shoved down your throat
No.
> Perhaps develop a more nuanced critique.
I believe most people who used Xcode perfectly know what I'm talking about.
This is a very strange question. It more correct to ask "In what way is AI NOT being shoved down your throat".
> Did you think that SwiftUI was shoved down your throat?
Yes
> Did you think that CoreData was shoved down your throat.
No
For the last ~15 years or so I only use Xcode on the command line sporadically. Prior to that I had to endure the full Xcode experience. I actually liked it between crashes!
Claude code 8 hours later: It's done, mate!
I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
Ever attempted this before at a large company and had success with it? I think I can count four times so far in ~15 years where people attempted to rewrite something medium/large-scale from scratch around me, was a success once, although scope was drastically cut at the end so almost a stretch to call it a success.
Boom! emacs is the IDE now. Bonuses all around.
It's not even rotting away. It was never completed.
It's XCode 26, and you still can't have the navigator and tabs work like in all other software on all other operation system, also including MacOS.
It's absolutely bonkers, and one of the reason's I decided to use Emacs if possible when working on "XCode projects".
XCode is good for project-reconfiguration and step-by-step debugging, but as an editor it's absolutely unusable.
In a project with code-only UIKit, only a smattering of SwiftUI for small components, and minimal dependencies, Xcode isn’t too bad of an experience and I’d say comparable to and in some ways better than Android Studio (that localization XML editor, not mention Gradle… ugh).
A lot of refactoring work across both platforms ends up being manual one way or another.
I haven't opened Xcode in months. My terminal: Claude writes code. build_sim. launch_app_sim. screenshot describe_ui.
What still requires Xcode: Instruments profiling, Signing/provisioning
For UI iteration, describe_ui returning the accessibility tree might actually be more useful to an agent than a preview screenshot.
Your workflow looks very interesting especially the describe_ui part, are you already able to do this today?
RenderPreview: Builds and renders a SwiftUI #Preview, returns snapshot
Surprisingly, this version does not require MacOS 26 (Tahoe).
- X.0 (September): bumps Swift, SDK versions, etc. It also tends to have a noticeably longer beta cycle than other releases. - X.3 or X.4 (around March): bumps Swift again and raises the minimum required macOS version.
Other releases in between are usually smaller updates that add features or fix bugs, but they don’t involve major toolchain-level or fundamental changes.
Today’s release doesn’t bump the Swift version, which suggests the core toolchain is essentially the same as Xcode 26.2—so it makes sense that the minimum macOS version wasn’t raised either.
I think it is required for any AI support. Xcode will run with limited features on earlier OS's.
I feel like Xcode knows how to work around xcodebuild’s shortcomings, and instead of fixing them they just wrapped Xcode in an MCP server.
Better than nothing I guess, but reliable CLIs would allow a whole ecosystem of tools.
> Apple’s Xcode now supports the Claude Agent SDK
Beyond that, I'd just keep using Claude Code in the terminal.
Or Axiom (https://charleswiltgen.github.io/Axiom/), which should now work great from within Xcode since Apple's using Claude Code SDK.
"Developers get the full power of Claude Code directly in Xcode—including subagents, background tasks, and plugins—all without leaving the IDE." — https://www.anthropic.com/news/apple-xcode-claude-agent-sdk