[HN Gopher] Xcode 26.3 - Developers can leverage coding agents d...
___________________________________________________________________
Xcode 26.3 - Developers can leverage coding agents directly in
Xcode
Author : davidbarker
Score : 198 points
Date : 2026-02-03 18:04 UTC (4 hours ago)
(HTM) web link (www.apple.com)
(TXT) w3m dump (www.apple.com)
| avaer wrote:
| I was really not expecting Apple to jump on this bandwagon, but I
| guess this was inevitable.
| bigyabai wrote:
| Thanks Apple, but "agentic coding" was already very possible
| without Xcode supporting it natively. Always gotta get your OKRs,
| I guess.
| wahnfrieden wrote:
| Xcode previews weren't possible via agents
| minimaxir wrote:
| [deleted]
| ianhawes wrote:
| > 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
| msie wrote:
| I wish they put their energy elsewhere like fix bugs, make
| faster.
| meetpateltech wrote:
| Anthropic's blog:
|
| > Apple's Xcode now supports the Claude Agent SDK
|
| https://www.anthropic.com/news/apple-xcode-claude-agent-sdk
| giancarlostoro wrote:
| 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.
| CharlesW wrote:
| Xcode is using the Claude Agent SDK, which means that you _"
| get the full power of Claude Code directly in Xcode--including
| subagents, background tasks, and plugins--all without leaving
| the IDE1"_. I assume that means iOS development plug-ins like
| Axiom2 should work as well.
|
| 1 https://www.anthropic.com/news/apple-xcode-claude-agent-sdk 2
| https://charleswiltgen.github.io/Axiom/
| cap10morgan wrote:
| 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.
| Someone wrote:
| 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.
| dd8601fn wrote:
| 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.
| etothet wrote:
| I came here to ask this question. I find the existing agentic
| coding integraton to be clunky and slow. I've had much better
| luck with my Xcode projects just using my agentic coding tool
| of choice in the CLI.
| OGEnthusiast wrote:
| I wonder how much of the recent Apple OS releases were done with
| "agentic coding".
| spzb wrote:
| UI design clearly was done by a chatbot.
| verdverm wrote:
| spray those menu icons everywhere
| radicaldreamer wrote:
| According to Mark Gurman (Bloomberg Apple beat reporter), Apple
| "runs on Claude."
| https://x.com/tbpn/status/2016911797656367199?s=61
| gbriel wrote:
| "custom versions of Claude"
| radicaldreamer wrote:
| The same thing they're doing with Gemini, creating custom
| versions, is likely what they've done with Claude and
| OpenAI models as well. They're likely evaluating all of
| them internally with employees all the time.
| richrichardsson wrote:
| That makes sense. The latest Sequoia update can't understand
| it's done updating and shows the "welcome" message every time
| I boot. I won't upgrade to Tahoe until absolutely necessary.
| It's like Apple is doing everything in its power to alienate
| their users.
| k_bx wrote:
| 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.
| OsamaJaber wrote:
| MCP support is the real story here Means you're not locked into
| Claude or Codex Can plug in whatever agent you want
| geooff_ wrote:
| 100% I hope they open more of the tooling to MCP, Xcode
| Instruments with real MCP support would be huge.
| flohofwoe wrote:
| 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.
| emchammer wrote:
| 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.
| embedding-shape wrote:
| 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.
| ndiddy wrote:
| 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.
| jajuuka wrote:
| I don't think this is it. I can only find one tweet from
| an Apple employee who said that they can't work on OSS
| and was looking for new maintainers. I am not sold that
| this is the whole truth.
|
| 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.
| dylan604 wrote:
| I worked for a non-FAANG company in California and the
| onboarding/exit process about side projects was one of
| the most annoying thing I've had to deal with. As far as
| why would silicon valley peeps put up with it...money.
| Big corps are worried that you will implement something
| you learned while on the job into one of your side
| hustles. Not defending it, just stating a bit of
| reasoning.
| saagarjha wrote:
| They can and do.
| 9dev wrote:
| This is such a ridiculous rule, it should make silicon
| valley collectively reach for their torches and
| pitchforks. Why would you ever accept something so
| egregiously overreaching like an employer dictating what
| you can do and cannot do, in your free time, with your
| own equipment??
| briandw wrote:
| 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.
| embedding-shape wrote:
| > 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.
| neutronicus wrote:
| 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.
| briandw wrote:
| You are of course correct. It's not likely to succeed.
| "Could work" doesn't mean high chance of success. I was
| trying to imply the opposite. It's just that Xcode has so
| much baggage that the previous attempts have been very
| compromised.
| brokencode wrote:
| 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.
| WillAdams wrote:
| 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.
| egorfine wrote:
| Bugfixes won't make shareholders happy while shoving AI down
| our throats will.
| XenophileJKO wrote:
| So you're still in the anger phase?
| Banditoz wrote:
| What does that mean?
| layer8 wrote:
| https://en.wikipedia.org/wiki/Five_stages_of_grief
| egorfine wrote:
| 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!
| doug_durham wrote:
| 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.
| egorfine wrote:
| > 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.
| lenkite wrote:
| > 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
| stalfosknight wrote:
| Copilot being added to the Xbox app on iOS is the latest
| ridiculous example I've seen of AI being shoved down
| everyone's throat.
| gwking wrote:
| 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.
| Ryder123 wrote:
| Ahhh ProjectBuilder...
| cosmic_cheese wrote:
| 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).
| sunnybeetroot wrote:
| Refactoring works half the time, Android Studio is much more
| stable for basic developer tooling.
| cosmic_cheese wrote:
| 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.
| ZenDroid wrote:
| 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.
| allthetime wrote:
| 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?
| flohofwoe wrote:
| 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.
| neutronicus wrote:
| 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.
| jahnu wrote:
| > The Debugger is even flakier than usual when Lambdas
| are involved.
|
| 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.
| plorkyeran wrote:
| Historically one of the big problems with Xcode has been
| that they _only_ dogfood. There's people on the team that
| have not touched any other IDE in decades. They've gotten
| used to all of the quirks, and just don't really know that
| things could be better. Every new improvement has to be
| designed from scratch rather than just ripping off what
| other IDEs do better.
|
| 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.
| saagarjha wrote:
| > 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 is so you can see function names for system
| frameworks. You can step into them if you want too even if
| Xcode tries to stop you doing it by default.
| Eric_WVGG wrote:
| 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; 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.
| saagarjha wrote:
| Nit: symbol files are copied _from_ a device.
| trinix912 wrote:
| 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.
| ASalazarMX wrote:
| > 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 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.
| spacedcowboy wrote:
| Honestly, that just sounds like it does things in an
| unfamiliar (to you) way. That's the flip side of the coin
| "This means you've learned to work around its
| shortcomings".
|
| 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
|
| Number of files read : 195
|
| ----------------------------
|
| 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.
| 9dev wrote:
| First time I tried it, I realised there is no way to have
| a terminal emulator panel. A bloody _terminal_. Like the
| most basic feature you could integrate into an IDE. No
| thank you.
| spacedcowboy wrote:
| I'm sitting here struggling to think of why the hell you
| need a terminal emulator in an IDE. There's a perfectly
| good terminal emulator called Terminal.app, it's usually
| the first thing I put on my dock after a fresh install of
| MacOS. I _like_ the terminal, but ... in an IDE ? I
| always wondered why Eclipse had one as well - it just
| seems like a wasted pane ?
|
| 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...
| timtimmy wrote:
| Even with IDEs that have a terminal view, I still much
| prefer using a separate terminal app.
| zamadatix wrote:
| I'll use both depending. Things which benefit from
| staying in the window context in the IDE window I use the
| IDE one, things which don't as much or are only
| tangentially related in an iTerm2/Terminal/Foot window
| (depending on the platform I'm on).
|
| 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.
| rob wrote:
| I use the built-in terminal "panel" inside VS Code/Cursor
| all the time. It's next to some other useful tab panels.
| Great for when you need to run commands for the current
| project but still want to chat in the sidebar or edit
| something else while it runs.
|
| 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.
| 9dev wrote:
| 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.
| DonHopkins wrote:
| Ha ha! You sound like a vi users asking an emacs user why
| the hell you need a shell window in emacs!
| lynndotpy wrote:
| I come from Linux land so I'm used to things being
| lightning fast, so using software on a Mac requires a
| thousand workarounds. A terminal integrated into the IDE
| is one of those necessary workarounds.
|
| MacOS has very very slow slow window- and desktop-
| switching (over one FULL second to switch from one
| desktop to another - this is not a joke!) so having a
| terminal integrated into the same application is very
| useful for maintaining flow for users developing on a
| single-screen Macbook.
| spacedcowboy wrote:
| I guess I'm not seeing what you're seeing. I don't often
| switch desktops - I tend to keep a project on a desktop,
| and there's enough real-estate for everything I need for
| that project right there - and I don't work on more than
| one project at a time.
|
| Window switching is instantaneous though, and I do that a
| _lot_
| FranklinJabar wrote:
| Oh you're why they add that. I just use a dedicated app.
| What's the benefit of putting it in the same window as
| the editor?
| 9dev wrote:
| Replied on a sibling too, but:
|
| > 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.
| semiinfinitely wrote:
| its almost tautological that a person who has been using
| xcode for 10 years would be incapable of seeing any flaws in
| it
| bromuro wrote:
| I also enjoy working with XCode. It has glitches and it is a
| bit slow, but I love the look and feel and it I am positively
| inspired working with it.
| indycliff wrote:
| There is barely anything wrong with Xcode. I'd rather it than
| the bloat that is Android Studio or Visual Code. Haters gonna
| hate. I also write apps for every Apple platform and really
| no complaints except I wouldn't mind a better Vim mode (it
| does however suffice!)
| sgt wrote:
| I haven't been using Xcode continuously for that long. But I
| recall being a pleasure every time I use it. Except when it
| crashed occasionally, but that was luckily rare.
|
| It sounds like OP doesn't like the way Xcode does things
| differently to other IDE's.
| snarf21 wrote:
| If nothing else, an update to the pbxproj file format would
| be life changing. Most of my time fighting git is dealing
| with project file merges.
| seankit wrote:
| as of Xcode 16, the default uses actual directories for
| folders instead of file references in the pbxproj file,
| which eliminates those annoying merge conflicts. at my work
| it took a bit of effort to move the project over to using
| folders but it was 100% worth it.
| st3fan wrote:
| It has become a meme to complain about Xcode. When I ask devs
| what they don't like about it it is usually very subjective
| or a misunderstanding. Take it all with a grain of salt. It
| is one of the most advanced and amazing IDEs out there IMO.
| perplex wrote:
| Xcode is abysmal on a large codebase. Freezes constantly on
| operations. The most useful features stall the entire
| program, things like: test navigator, quick open files,
| debugger, etc..
|
| But I agree that Xcode runs fine on small projects and recent
| version feel stable compare to past releases.
| jbm wrote:
| I sometimes have to build code for the apple watch. Getting
| it to pair with XCode is incredibly frustrating and is the
| opposite of what you would expect.
| Aloisius wrote:
| While I don't quite have the same problems as others have,
| there are some pain points.
|
| Stepping through the debugger too fast will sometimes put the
| debugger in a weird state where step never breaks again and
| all other breakpoints stop working.
|
| Git pull through the UI with stash and merge can blow away
| your local changes if there is a conflict. The changes aren't
| stashed. They're just gone.
|
| Xcode likes to sometimes recompile files that haven't changed
| slowing everything down, sometimes significantly depending on
| the file. No idea why.
|
| It can get _very_ confused if you 're missing a parenthesis
| in the wrong place in a SwiftUI View leading to opaque swift
| compiler errors about code being too complex.
|
| Even mildly complex use of a swift #Predicate will cause an
| error about it being too complex forcing you to break them
| down into smaller pieces and even then it takes _far_ too
| long to build even on a brand new machine.
|
| The simulators are quite slow to start/update/run and xcode
| sometimes fails to shut them down completely when quitting
| leading to them just continually running eating memory unless
| you kill the processes manually.
|
| The simulators also are really limited in their
| functionality. No background processes, spotlight, network
| degradation simulation, out of memory killer, etc.
|
| The profiler sometimes just fails to start an app correctly,
| immediately ending a run forcing you to close the profiler
| and reopen it again before it'll start working.
|
| Symbol refactor (rename) can be painfully slow where the UI
| just locks up until it can find all the references.
|
| Xcode likes to duplicate package dependencies in xcodeproj.
| It just creates new hashes for the same library and adds it
| as a dependency over and over again, so when the link phase
| happens, it adds libraries repeatedly over and over and over
| again unless you manually clear them out. Not sure what
| causes this, perhaps updating the version or merges between
| users.
| ddalex wrote:
| > Xcode really needs a couple of years of pure bugfix
|
| Claude code 8 hours later: It's done, mate!
| walt_grata wrote:
| Come on Claude, making it not start isn't the same as fixing
| the bugs
| markbao wrote:
| 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.
| eptcyka wrote:
| 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.
| neutronicus wrote:
| For a certain-size project it really is not.
|
| 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.
| gbalduzzi wrote:
| > Single files in our codebase already blow the Copilot
| query token limit.
|
| This tells more about your code quality that about
| copilot, and I'm not a fan of copilot
| neutronicus wrote:
| I disagree.
|
| 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.
| SgtBastard wrote:
| Claude, with a modicum of guidance from an engineer
| familiar with your monolith, could could write
| comprehensive unit tests of your existing system, then
| refactor it into coherent composable parts, in a day.
|
| Not doing so _while senior management demands the use of
| AI augmentation_ seems odd.
| bigstrat2003 wrote:
| > AI is a key part of software engineering now.
|
| 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.
| periodjet wrote:
| You'd have to be deeply ensconced in a particular kind of
| bubble to hold this belief.
| gloosx wrote:
| ...or you have to be deeply entrenched in another kind of
| bubble to believe the opposite xD
| isodev wrote:
| > AI is a key part of software engineering now
|
| 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).
| josteink wrote:
| > Building castles in the sky while the foundation is rotting
| away :/
|
| 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.
| OscarTheGrinch wrote:
| Just in time for AI to go all tits up.
| jonathanstrange wrote:
| 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.
| almosthere wrote:
| Does agents.md allow for automatic discovery of mcp tools (Tools:
| run ./tool-discovery.sh)
| classicsc wrote:
| 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.
| mohsen1 wrote:
| I built an entire iOS app without opening Xcode UI even once. Why
| so many iOS engineers prefer XCode?
| radicaldreamer wrote:
| 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+?
| s_dev wrote:
| >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.
| wahnfrieden wrote:
| Some influential iOS devs such as @dimillian and @steipete
| have moved away from Xcode or even xcodebuild where
| possible.
| mohsen1 wrote:
| I wish I was young! I have used Xcode in the past. It's
| just way too slow and anything it does, other IDEs do
| faster for me.
| thedangler wrote:
| First time I tried it, claude built all the files in the wrong
| directory lol. It's working fine now.
| mrtksn wrote:
| 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...
| cyberax wrote:
| 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.
| SgtBastard wrote:
| _Fancy_ while() loops is how I describe them.
| enraged_camel wrote:
| 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?
| pjmlp wrote:
| Goodbye CoPilot plugin, yet another platform Microsoft loses on.
|
| https://github.com/github/CopilotForXcode
| geooff_ wrote:
| 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.
| thought_alarm wrote:
| Release notes: https://developer.apple.com/documentation/xcode-
| release-note...
|
| Surprisingly, this version does not require MacOS 26 (Tahoe).
| r2vcap wrote:
| 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.
| w10-1 wrote:
| > 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.
| f0rmatfunction wrote:
| Agreed - I tried installing Xcode26.3 on my mac running
| Sequoia and there's no "intelligence" pane in Xcode settings
| to connect Claude like there is in the docs.
| SirMaster wrote:
| 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...
| mikeocool wrote:
| "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.
| geooff_ wrote:
| It doesn't interact with sim. You still need XcodeBuildMCP for
| that. Hopefully future releases implement this functionality.
| CharlesW wrote:
| > _You still need XcodeBuildMCP for that._
|
| 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
| HaloZero wrote:
| 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)
| forrestthewoods wrote:
| 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!
| 9dev wrote:
| Why would you ever want a debugger that isn't integrated with
| the code editor..? I will never not want to debug code when the
| current breakpoint and evaluated expressions aren't visible in
| the code itself.
|
| I mean, look at debugging in IntelliJ:
| https://resources.jetbrains.com/help/img/idea/2025.3/hotswap...
|
| As opposed to the terminal:
| https://cdn.hashnode.com/res/hashnode/image/upload/v16980433...
| r2vcap wrote:
| 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).
| hn-acct wrote:
| swift --version is showing 6.2.4 for me
| r2vcap wrote:
| Thanks for clarifying. Since I don't use the LLM features in
| Xcode, I'm leaning toward skipping this version.
| Oras wrote:
| As MKBHD would say, welcome to 2026, Apple.
| mlajtos wrote:
| Does it support API key access or only Claude.ai subscription?
| argsnd wrote:
| Both
| anupamchugh wrote:
| 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.
| HaloZero wrote:
| I still haven't found a useful way to replicate preview when
| iterating quickly on a view (though it's an edge case)
| geooff_ wrote:
| XcodeMCP (Native MCP added in 26.3) Implements this with
| RenderPreview
|
| RenderPreview: Builds and renders a SwiftUI #Preview, returns
| snapshot
| mckn1ght wrote:
| 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.
| MillionOClock wrote:
| Multiple config files of Xcode projects are not publicly
| documented as far as I remember and personally I have preferred
| to require my agents not to modify them out of fear it might
| break something and be hard to fix. I don't know how agentic
| programming will work in Xcode but I would _expect_ it to do it
| using a safer approach, so that 's also another case where it
| might have an advantage.
|
| Your workflow looks very interesting especially the describe_ui
| part, are you already able to do this today?
| neutronicus wrote:
| Can XcodeBuildMCP spit out definitions of C++ symbols? Did
| Apple just accidentally release a LSP server for Xcode
| projects? That would be sick.
| meisel wrote:
| 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.
| arjie wrote:
| 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.
| Iridiumkoivu wrote:
| The cancer is spreading...
| va1a wrote:
| And yet, it still takes 5 minutes for my canvas preview to load,
| and one in 20 times it crashes the whole app.
| msvan wrote:
| One thing that would be genuinely useful would be the ability to
| integrate Claude with the Metal debugger somehow, to get
| automated analysis of GPU profiling. The .gputrace format is
| proprietary and cannot be easily analyzed, and it seems that the
| new "agentic coding" integration in Xcode also does nothing to
| expose this data to LLMs. Oh well.
| jon889 wrote:
| It keeps asking if I want to run the app after building it. I
| reply yes, and then it says it can't do that, tries to build
| again by command line and gets stuck... (even with approving the
| command)
| scosman wrote:
| All of this could be avoided if their CLIs worked reliably and
| well. Instead the randomly fail (you fix them by running the same
| task from Xcode), and output 5k lines of useless unstructured
| output (tools like xcbeautify try to help but it's an uphill
| battle).
|
| 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.
| searls wrote:
| This is true of the CLIs that start with `xcode` but not of the
| CLIs that start with `swift`. As `swift-format` and `swift-
| test` have come into their own, they're just as reliable as any
| other language ecosystem. And the difference is indeed
| staggering. I wrote this guide last summer on extracting all
| your app's code into a (nonsensically necessary) Swift package
| dependency simply so you can test it with Swift Testing
| https://justin.searls.co/posts/i-made-xcodes-tests-60-times-...
| scosman wrote:
| Yes! If you're lucky enough to be writing a library you are
| in good shape. Swift did things right.
|
| I have UI and UI tests and xcodebuild is my nemesis.
| wahnfrieden wrote:
| Did they add ability to parallelize agents? If not, this remains
| useless.
| cyrusradfar wrote:
| _OT: Rant_
|
| 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.
| olivia-banks wrote:
| I agree with you, it's infuriating. I think it's been loading
| faster recently (maybe?), but it still takes like 10 seconds.
|
| 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
|
| Where ${whatever} is in {plain-text, json, source-code, ...}.
| I'm sure there's a way to automate this through parsing
| `lsregister -dump`, but have a script I run on every Mac I have
| that sets TextEdit as the default instead of XCode for a bunch
| of file types :-)
| DonHopkins wrote:
| > sleep(rand())
|
| 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.
| wlesieutre wrote:
| I like to take a few minutes to admire the content
| underneath/behind my sidebars
| dylan604 wrote:
| I'm confused, how have you not reassociated the files with the
| app of your choosing? Is Xcode somehow changing associations
| back? Does it do it only at updates?
|
| 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.
| nerdsniper wrote:
| There is a way to do it, but it's not the most typical way
| MacOS users do it for everything else, which involves Right
| Click->Open With->Other->Always Open With. Xcode's file
| associations are super aggressive.
|
| 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.
| crazygringo wrote:
| Not something I've ever experienced. Open As... Always
| works just fine.
| c-fe wrote:
| select in finder the file that currently opens with XCode,
| then press Cmd+i. It opens the information panel. There in
| the Open with section, you can chose the app and then also
| Change all to not use XCode.
| dwaite wrote:
| > Xcode's file associations are super aggressive.
|
| They are the same Info.plist format as every other MacOS
| application.
| cyrusradfar wrote:
| You're right that you can fix it via Get Info - Change All.
|
| 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.
| gloosx wrote:
| >Not once has it ever changed on me.
|
| I don't know how did you achieve it, but I was doing it
| countless times.
|
| Open with -> other -> enable all applications -> always open
| with.
|
| For a short while it works, but somehow, something always
| reverts it back to xcode. Maybe it is restart. Maybe it is
| little evil cron job discreetly changes it back to xcode, but
| I was never able to get rid of it. It is happening to me on
| many different machines since Sierra. One calm day I casually
| double-click an STL or JSON and it prompts me to install some
| xcode packages, and I get angry at the machine.
| aniforprez wrote:
| There was a time I was interested in building for MacOS.
| Installing, opening and trying to use Xcode killed that pretty
| quick. I've never seen an IDE this behind in terms of usability
| from the competition.
| walthamstow wrote:
| The hijacking of file associations is one of the most awful and
| malicious things about macOS. You can set it to whatever you
| want, when Apple decide they want to, your CSVs will go to
| Numbers, JSONs go to Xcode.
| anthk wrote:
| Can't wait to Tarot or I-Ching based programming.
| nofunsir wrote:
| Why is it still called Xcode, if they abandoned the name OS X?
| nipponese wrote:
| don't go creating problems where we don't need solutions.
___________________________________________________________________
(page generated 2026-02-03 23:00 UTC)