https://claude.com/blog/building-agents-with-the-claude-agen...
From September 29, 2025
> Apple’s Xcode now supports the Claude Agent SDK
There may be other improvements.
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.
I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
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!
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'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?
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.
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, all the "let me run weird functions and interact with stuff" is in the bottom panel, where the terminal, debug and logs are. 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.
- 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.
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 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 neet to open my Apple account in the browser and accept a new stupid little change in their kilometric EULA that I always pretend I've read carefully". Things like this could be handled better.
Claude code 8 hours later: It's done, mate!
Why wouldn’t engineers prefer tools they’ve been using (mostly happily) for a decade+?
I don't think it's a serious question or the person is very young.
To answer the question. Xcode is the default IDE for iOS development. The default option will always be a practical choice.
JetBrains or Anthropic could get bought by a larger company or dismantled by the government somehow. Should anything happen to Apple (unlikely as that may seem) the entire iOS ecosystem would be gone as well negating any need for a default.
Yesterday in few hours I released an update for my mac App that I haven’t been working on for over a year. The update easily performed as expected, did a few small manual touches on the UI and the app just got approved on AppStore(like minutes ago)[0].
This is very good because normally I would not remember much about the code, so doing an update for a long forgotten code becomes huge pain.
Good for Apple but I think I feel most comfortable on Codex app. I think I like having the AI separated from the IDE so I feel in control in the IDE.
[0] Codex implemented the functionality demo on the paywall, if you want to see it: https://apps.apple.com/us/app/crystalclear-sound-switcher/id...
"Agentic this", "agentic that"... It's literally just an LLM in a while() loop with some exposed tools.
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 wonder if they used this internally to write iOS 26? Would explain some things...
Beyond that, I'd just keep using Claude Code in the terminal.
Or is Xcode developed not using Xcode...
(I also 2nd the question about what's really the difference between this and the Xcode 26.2)
* text editor with intellisense * build system * visual debugger * CLI coding agent
It’s totally fine if those four things are different. In fact I actually probably prefer them to be different. Having an all-in-one IDE is a complete and total non-goal.
People have historically confused the first three as needing to be a single IDE. This has always been wrong. The number of people who think you can’t debug with Visual Studio if the exe wasn’t built from a .sln is shocking. They’re all independent!
https://xcodereleases.com hasn’t shown anything since last December, so I assumed Apple had taken a breather from Xcode development, but they released an RC build today?
Anyway, the Swift version seems unchanged (6.2.3), so is this update mainly for the so-called “Coding Intelligence” features?
In any case, Xcode isn’t my favorite IDE—it’s too slow and feels quite different from other major IDEs—so I probably won’t use it for day-to-day coding (though it’s fine for building and debugging).
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.
RenderPreview: Builds and renders a SwiftUI #Preview, returns snapshot
avaer•1h ago