Building castles in the sky while the foundation is rotting away :/ Xcode really needs a couple of years of pure bugfix and optimization releases instead of hype-chasing.
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.
> I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points.
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 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.
My pain points are mostly in the CPU debugger (since I'm not using much of the actual "IDE features" of Xcode except the regular edit-compile-debug loop anyway.
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.
Yes, I develop C++ on XCode and Visual Studio. I've recently started using XCode more because the performance on my Windows tower has become abominable in the past couple years and the M1 laptop is still snappy.
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.
Like you, I think that Xcode maybe gets a worse rap than it deserves, but it's also endlessly frustrating.
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.
Mostly the fact that for the past 10 years they've been adding new features but never finished them and taken the time to properly bugfix them along the way. Just a few I ran into recently:
- 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 is not hype-chasing. AI is a key part of software engineering now. For this to be absent from Xcode would be an existential risk for the future of the product.
Claude Code from the terminal is servicable enough. Yet I cannot open the same project from different versions of Xcode without some manual finnagling. Xcode is at no existential risk for it is the only tool you are allowed to use to reach your audience on the app store. Don’t be ridiculous. The reason Xcode is as broken as it is today is because of the same exact reason. The developer experience need not be great, as long as you can coax the trash fire of a toolchain to upload a signed app to AppStoreConnect, there is 0 incentive for Apple to put any time into the tool.
It's a damn shame, the hardware is pretty amazing and I wish they just had like one person who cared about Linux working at Apple and then make a small promise to not rugpull Linux users.
I think one thing that shows Apple's position towards open source in general is that they don't allow their employees to work on open source projects in their own time and using their own equipment. Before anyone brings up that California labor code provision, it has a carve-out for "activities that relate to the employer's business". Since Apple is big enough and has their fingers in enough pies that they can credibly say that virtually any open source projects developed by Apple employees are related to their business, I would be wary about fighting them in court over this.
For the record, I started using Xcode before it was called that and people have said this almost every year since. As I recall there was a big hit to its quality when they converted it to obj-c’s short lived garbage collection, and it felt like it never got back to reliable after that.
In what way is "AI being shoved down you throat"? Did you think that SwiftUI was shoved down your throat? Did you think that CoreData was shoved down your throat. Perhaps develop a more nuanced critique.
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!
Idk, I feel like these coding assistant features aren’t that hard to add, but can provide a lot of value to developers. Most or all popular IDEs now support similar features.
I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
Yeah, I'd like to see another OS release like to Snow Leopard (10.6.x) which had as a prime focus simplification and so forth w/o adding many (any?) features.
True that Xcode needs yet another rebuild from scratch. If they forked it and abandoned the old project file and went with a swift first approach, could work. However adding support for Claude is still a huge win. Could lead the way to making the transition to a sane IDE possible / reasonable. This would require leadership that’s completely absent at the company.
> If they forked it and abandoned the old project file and went with a swift first approach, could work.
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.
A full rebuild might be throwing out the baby with the bath water. As someone who’s been using it since it was known as Project Builder, bugs seem mostly concentrated in the XIB/Storyboard editor (formerly known as a Interface Builder), SwiftUI live preview, and SwiftPM package resolve.
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).
Because it's developed by JetBrains (with Google contributions), a company whose main business is writing really good IDEs. Apple on contrary is a hardware company that happens to build software. If they had delegated the XCode development to JetBrains, we would have had a great IDE for macOS/iOS development too. AppCode was damn good with zero support from Apple side, and despite the fact that JetBrains always needed to catch-up with Apple's breaking changes.
I've not found Android Studio to be particularly amazing for those kinds of features either. Sometimes they work, sometimes they half-work, and on occasion I've had them do the wrong thing entirely.
A lot of refactoring work across both platforms ends up being manual one way or another.
I still open Xcode for every branch after having Claude do an initial implementation, to review the changes using its version editor, step through code using the IDE’s various code navigation features, and build/run to manually validate the changes. I do have claude analyze and test, though.
From my years of iOS development—and based on https://xcodereleases.com typically ships two major Xcode updates each year:
- 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.
When I see Activity Monitor that doesn't show tabs until you nearly go full screen – all I can think is that this shit product was built even before vibecoding was a thing. Truly ahead of its time.
I tried the three provider types with xcodes current agent integration pane and just trying to use them crashed xcode itself so badly that the ide couldn’t even be launched.
FTA: “In addition to these built-in integrations, Xcode 26.3 makes its capabilities available through the Model Context Protocol, an open standard that gives developers the flexibility to use any compatible agent or tool with Xcode.”
"visually by capturing Xcode Previews" is probably the thing that will make this worthwhile, also if it's able to interact with the simulator that would be killer.
Beyond that, I'd just keep using Claude Code in the terminal.
Okay, this is going to help somewhat. But what I wish I had was command-line access to everything in a reliable way. Developing for iOS I frequently end up with imperfect debugging information exposed to a Claude Code etc. agent. I'll try to get this today and see.
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).
This is huge news. Human-in-the-loop development is essential for actual software velocity gains. The current tooling around agent enabled iOS dev leaves a lot to be desired. Every time I work on web-dev tasks I'm jealous of the tooling.
My experience with AI with its predecessor, Xcode 26.2, was _really_ bad. One bug made it objectively unusable, and there were lots of fun issues/huge functionality gaps on top of that. Apple doesn't really seem to "get" agent-based coding, but I'm curious to see the results of other braver souls with 26.3.
I'm looking forward to trying the SwiftUI preview integration, though from my experience using the xcodebuildmcp and axe tools to let agents run simulators and capture screenshots, expectations will be low. It seemed like the models were capable of identifying issues like "button that should be there is not displayed", but not identifying when the layout is wrong or some element is too big.
So far I find OpenAI’s Codex app to be the right approach for me. I can’t stand AI integrated IDE’s, it creeps me out when code starts changing at a phase that I can’t follow.
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.
Who cares about AI’s embedded in IDEs? Here’s the tooling I need
* 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!
I have not been able to switch to Opus 4.5 in XCode. It defaults to Sonnet 4.5 and I couldn't find where to change it (or if it's possible). Anyone know?
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.
My annoyance is that it sounds like I can't just use Claude Code directly in XCode? I like how Zed does it, it's not perfect, but it works really nicely.
Building castles in the sky while the foundation is rotting away :/ Xcode really needs a couple of years of pure bugfix and optimization releases instead of hype-chasing.
Honest question.
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?
> I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points.
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 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.
My pain points are mostly in the CPU debugger (since I'm not using much of the actual "IDE features" of Xcode except the regular edit-compile-debug loop anyway.
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.
Yes, I develop C++ on XCode and Visual Studio. I've recently started using XCode more because the performance on my Windows tower has become abominable in the past couple years and the M1 laptop is still snappy.
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.
Like you, I think that Xcode maybe gets a worse rap than it deserves, but it's also endlessly frustrating.
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.
Mostly the fact that for the past 10 years they've been adding new features but never finished them and taken the time to properly bugfix them along the way. Just a few I ran into recently:
- 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.
its almost tautological that a person who has been using xcode for 10 years would be incapable of seeing any flaws in it
This is not hype-chasing. AI is a key part of software engineering now. For this to be absent from Xcode would be an existential risk for the future of the product.
Claude Code from the terminal is servicable enough. Yet I cannot open the same project from different versions of Xcode without some manual finnagling. Xcode is at no existential risk for it is the only tool you are allowed to use to reach your audience on the app store. Don’t be ridiculous. The reason Xcode is as broken as it is today is because of the same exact reason. The developer experience need not be great, as long as you can coax the trash fire of a toolchain to upload a signed app to AppStoreConnect, there is 0 incentive for Apple to put any time into the tool.
A lot of macOS needs that. There are some terrific ideas under the hood, but it’s as if people left halfway through implementing them.
It's a damn shame, the hardware is pretty amazing and I wish they just had like one person who cared about Linux working at Apple and then make a small promise to not rugpull Linux users.
I think one thing that shows Apple's position towards open source in general is that they don't allow their employees to work on open source projects in their own time and using their own equipment. Before anyone brings up that California labor code provision, it has a carve-out for "activities that relate to the employer's business". Since Apple is big enough and has their fingers in enough pies that they can credibly say that virtually any open source projects developed by Apple employees are related to their business, I would be wary about fighting them in court over this.
For the record, I started using Xcode before it was called that and people have said this almost every year since. As I recall there was a big hit to its quality when they converted it to obj-c’s short lived garbage collection, and it felt like it never got back to reliable after that.
Bugfixes won't make shareholders happy while shoving AI down our throats will.
In what way is "AI being shoved down you throat"? Did you think that SwiftUI was shoved down your throat? Did you think that CoreData was shoved down your throat. Perhaps develop a more nuanced critique.
> In what way is "AI being shoved down you throat"?
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
> In what way is "AI being shoved down you throat"?
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.
So you're still in the anger phase?
Well yes but actually 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!
What does that mean?
> Xcode really needs a couple of years of pure bugfix
Claude code 8 hours later: It's done, mate!
Come on Claude, making it not start isn't the same as fixing the bugs
Idk, I feel like these coding assistant features aren’t that hard to add, but can provide a lot of value to developers. Most or all popular IDEs now support similar features.
I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
Yeah, I'd like to see another OS release like to Snow Leopard (10.6.x) which had as a prime focus simplification and so forth w/o adding many (any?) features.
True that Xcode needs yet another rebuild from scratch. If they forked it and abandoned the old project file and went with a swift first approach, could work. However adding support for Claude is still a huge win. Could lead the way to making the transition to a sane IDE possible / reasonable. This would require leadership that’s completely absent at the company.
> If they forked it and abandoned the old project file and went with a swift first approach, could work.
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.
In this particular case they just need to release a tool that properly generates compile_commands.json and .clangd from a .xcodeproj.
Boom! emacs is the IDE now. Bonuses all around.
A full rebuild might be throwing out the baby with the bath water. As someone who’s been using it since it was known as Project Builder, bugs seem mostly concentrated in the XIB/Storyboard editor (formerly known as a Interface Builder), SwiftUI live preview, and SwiftPM package resolve.
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).
Refactoring works half the time, Android Studio is much more stable for basic developer tooling.
Because it's developed by JetBrains (with Google contributions), a company whose main business is writing really good IDEs. Apple on contrary is a hardware company that happens to build software. If they had delegated the XCode development to JetBrains, we would have had a great IDE for macOS/iOS development too. AppCode was damn good with zero support from Apple side, and despite the fact that JetBrains always needed to catch-up with Apple's breaking changes.
I've not found Android Studio to be particularly amazing for those kinds of features either. Sometimes they work, sometimes they half-work, and on occasion I've had them do the wrong thing entirely.
A lot of refactoring work across both platforms ends up being manual one way or another.
When do you actually need to open Xcode if you have XcodeBuildMCP [0]?
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.
I still open Xcode for every branch after having Claude do an initial implementation, to review the changes using its version editor, step through code using the IDE’s various code navigation features, and build/run to manually validate the changes. I do have claude analyze and test, though.
I still haven't found a useful way to replicate preview when iterating quickly on a view (though it's an edge case)
XcodeMCP (Native MCP added in 26.3) Implements this with RenderPreview
RenderPreview: Builds and renders a SwiftUI #Preview, returns snapshot
MCP support is the real story here Means you're not locked into Claude or Codex Can plug in whatever agent you want
100% I hope they open more of the tooling to MCP, Xcode Instruments with real MCP support would be huge.
Release notes: https://developer.apple.com/documentation/xcode-release-note...
Surprisingly, this version does not require MacOS 26 (Tahoe).
From my years of iOS development—and based on https://xcodereleases.com typically ships two major Xcode updates each year:
- 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.
> this version does not require MacOS 26
I think it is required for any AI support. Xcode will run with limited features on earlier OS's.
I wonder how much of the recent Apple OS releases were done with "agentic coding".
According to Mark Gurman (Bloomberg Apple beat reporter), Apple “runs on Claude.” https://x.com/tbpn/status/2016911797656367199?s=61
UI design clearly was done by a chatbot.
spray those menu icons everywhere
When I see Activity Monitor that doesn't show tabs until you nearly go full screen – all I can think is that this shit product was built even before vibecoding was a thing. Truly ahead of its time.
Anthropic's blog:
> Apple’s Xcode now supports the Claude Agent SDK
https://www.anthropic.com/news/apple-xcode-claude-agent-sdk
I am already using Claude in Xcode 26.2. What did they change / add specifically in 26.3? It's not super clear behind the marketing haze.
I tried the three provider types with xcodes current agent integration pane and just trying to use them crashed xcode itself so badly that the ide couldn’t even be launched.
FTA: “In addition to these built-in integrations, Xcode 26.3 makes its capabilities available through the Model Context Protocol, an open standard that gives developers the flexibility to use any compatible agent or tool with Xcode.”
There may be other improvements.
"visually by capturing Xcode Previews" is probably the thing that will make this worthwhile, also if it's able to interact with the simulator that would be killer.
Beyond that, I'd just keep using Claude Code in the terminal.
It doesn't interact with sim. You still need XcodeBuildMCP for that. Hopefully future releases implement this functionality.
Okay, this is going to help somewhat. But what I wish I had was command-line access to everything in a reliable way. Developing for iOS I frequently end up with imperfect debugging information exposed to a Claude Code etc. agent. I'll try to get this today and see.
Wait…
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).
swift --version is showing 6.2.4 for me
Thanks for clarifying. Since I don’t use the LLM features in Xcode, I’m leaning toward skipping this version.
This is huge news. Human-in-the-loop development is essential for actual software velocity gains. The current tooling around agent enabled iOS dev leaves a lot to be desired. Every time I work on web-dev tasks I'm jealous of the tooling.
My experience with AI with its predecessor, Xcode 26.2, was _really_ bad. One bug made it objectively unusable, and there were lots of fun issues/huge functionality gaps on top of that. Apple doesn't really seem to "get" agent-based coding, but I'm curious to see the results of other braver souls with 26.3.
I don't think I'm ready for my phone apps to get even more sloppy...
I wonder if they used this internally to write iOS 26? Would explain some things...
Just in time for AI to go all tits up.
I'm looking forward to trying the SwiftUI preview integration, though from my experience using the xcodebuildmcp and axe tools to let agents run simulators and capture screenshots, expectations will be low. It seemed like the models were capable of identifying issues like "button that should be there is not displayed", but not identifying when the layout is wrong or some element is too big.
I was really not expecting Apple to jump on this bandwagon, but I guess this was inevitable.
Does it support API key access or only Claude.ai subscription?
Both
And yet, it still takes 5 minutes for my canvas preview to load, and one in 20 times it crashes the whole app.
The cancer is spreading...
First time I tried it, claude built all the files in the wrong directory lol. It's working fine now.
Ask MKBHD would say, welcome to 2026 Apple
So far I find OpenAI’s Codex app to be the right approach for me. I can’t stand AI integrated IDE’s, it creeps me out when code starts changing at a phase that I can’t follow.
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...
Who cares about AI’s embedded in IDEs? Here’s the tooling I need
* 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!
I have not been able to switch to Opus 4.5 in XCode. It defaults to Sonnet 4.5 and I couldn't find where to change it (or if it's possible). Anyone know?
I built an entire iOS app without opening Xcode UI even once. Why so many iOS engineers prefer XCode?
Is this bait? XCode has been a mainstay of iOS development ever since iOS was introduced and is a successor to Interface Builder on the Mac.
Why wouldn’t engineers prefer tools they’ve been using (mostly happily) for a decade+?
>Is this bait?
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.
As long as it's purely opt-in and before opting in no data is ever sent to some server and no source code can be changed by it, I'm okay with it.
Maybe now they have Claude inside Xcode, the Xcode developers can work faster on fixing all the Xcode issues.
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)
I wish they put their energy elsewhere like fix bugs, make faster.
Thanks Apple, but "agentic coding" was already very possible without Xcode supporting it natively. Always gotta get your OKRs, I guess.
Does agents.md allow for automatic discovery of mcp tools (Tools: run ./tool-discovery.sh)
My annoyance is that it sounds like I can't just use Claude Code directly in XCode? I like how Zed does it, it's not perfect, but it works really nicely.
How about adding a horizontal scroll to sidebars? No?
"Agentic this", "agentic that"... It's literally just an LLM in a while() loop with some exposed tools.
Goodbye CoPilot plugin, yet another platform Microsoft loses on.
https://github.com/github/CopilotForXcode
[deleted]
> The Claude Agent SDK is a collection of tools that helps developers build powerful agents on top of Claude Code.
https://claude.com/blog/building-agents-with-the-claude-agen...
From September 29, 2025
Thanks. I hate it.