Xcode 26.3 – Developers can leverage coding agents directly in Xcode (opens in new tab)

Do you think the pool of devs who can write rn + ts is bigger or smaller than native devs?

Ha! Curious - as an old timer, how you enjoying this new vibe coding world?

lol... people that complain about XCode don't know how well they have compare to what it was before.

I started my work on the J2ME era as well. Had to use textpad for development, and maybe eclipse at some point (which was pretty decent). Tools and simulators were all over the place.

Zero so far - we've never had a single ding in 30+ submissions. Will update here if we do.

server driven user experience - server controls components, layout and navigation so teams "can ship quick".

every client ends up writing a parser, and then teams fight over who is responsible for doing work.

how good does that sound!

Just a good CLI would be even better, usable by humans, CI scripts and agents.

Classic Apple; cannot possibly be the same developers (not) doing this kind of thing after all these years, so it must be a systemic issue.

Only theoretically at this point, though they will tend to speak confidently enough about such untested capabilities so as to cause millions in investment losses to others. One would think a hardware manufacturer that's teetering on the abyss would go full out and implement a vLLM interface (maybe a folder of local models that can be downloaded as components in the Xcode-way and also a router too), but their NIH mentality has them tripping over their own Graydey's. There is nothing special about Apple Silicon except the head start they had and that they're squandering.

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.

> 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.

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.

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.

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.

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.

it's truly a bismal experience compared to what else is out there (my experience is with rust, python and ts inside vsc).

Often autocomplete is hopeless and doesn't help you with the most simple things like picking from multiple initializers, or changing to a different signature of a function call.

the project setup is this mystery Xcode project file, instead of a standardized yml or something that anyone can modify and understand.

I have to say provisioning has improved a lot. I remember back in 2008, it was really a pain to get anything working.

This is not necessarily about Xcode, but maybe it should be: screen shots for your app. they need screenshots for 454 device types, and zero automation in their own tooling.

the layout is also very inflexible. they dictate a couple of panels and that's how you _must_ use them. that's unlike any other modern IDE.

I have never used any other IDE where quitting and relaunching it would fix build errors.

And, this isn’t strictly XCode, but my least favorite thing about writing apps for apples platforms is all the admin overhead. You need an Apple development account, signing certificates, app groups, entitlements… just let me compile my code man.

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.

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.

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.

its almost tautological that a person who has been using xcode for 10 years would be incapable of seeing any flaws in it

Xcode is perpetually decade(s) behind the curve. VSCode is so much more advanced, even Atom 10 years ago was.

To put it in a language Apple understands, it's like forcing music producers to use GarageBand when everyone else is on Logic.

Inflexible window layout. (For example, suppose you want to see breakpoints list, call stack, and find results simultaneously. You can't, as they all share the same panel. Which is always on the left of the window.)

As others have said, I suspect you've just grown accustomed to its quirks and defects and learned to work around them. For example... * always refresh X before doing Y. * if you see this signing error, clear this cache. * don't try to drag this file here because it gets linked in the wrong way ...and so on.

If you were able to use a magical, fast, bug-fixed, version where everything 'just worked' at pace, I imagine you would begin to realise just how much you have been putting up with!

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.

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.

putting a build on your own apple watch is horrific.

it constantly disconnects, requires restarts and other nonsense techniques. i legit do not know how you can not be running into these problems if you are developing on those platforms.

I've been using Xcode since it was Project Builder. It has improved in many ways. And since the advent of the App Store, the insufferable/inexcusable nightmare of "signing" has vastly improved.

Most of the problems I encounter now resulted from the fiasco that is SwiftUI. I used to really enjoy development, and built a few mobile apps singlehandedly... even at a well-known company or two. But now I'm struggling to get one chunk of functionality at a time done on a from-scratch app, because SwiftUI and the underlying "reactive" paradigm were so poorly conceived and defectively implemented. Development is now miserable drudgery, and I never feel confident about the result. The absurd gymnastics to trick the UI into doing what you want; and the hypocritical, conflicting edicts for Swift and SwiftUI... it all barely hangs together.

The fact that Apple rolled out a new UI toolkit that didn't support the most fundamental paradigm in mobile applications, a stack of progressive views for the user to proceed through, tells you how far off the rails they went since introducing the original and solid SDK.

And testing is going to be a nightmare... or simply futile.

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.

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!)

> 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.

> 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).

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.

  > converted it to obj-c’s short lived garbage collection

that was around xcode 4 iirc, that was when interface builder was ducktaped (or maybe i should say intermixed) with xcode (née project builder) to disastrous results in terms of performance... its never really recovered imo...

Ahhh ProjectBuilder...

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.

So you're still in the anger phase?

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.

Come on Claude, making it not start isn't the same as fixing the bugs

> 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.

Why would being "swift first" affect anything? Why do you assume Xcode isn't already full of Swift code?

Refactoring works half the time, Android Studio is much more stable for basic developer tooling.

The dozens and dozens of simulators it installs without asking... which kill your system's audio capabilities for some reason: https://discussions.apple.com/thread/256140785

But the best part is what it DOESN'T install when you think you've updated. You get on a plane and settle in for some work, only to be prompted to download and install a bunch of required crap you weren't told about. OH WELL, says Apple, your time is FREE!

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.

XCode re-associates its preferred filetypes every time you update it, or at least pretty reliably does for me

>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.

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.

I've never actually installed Xcode (I need to run specific versions so just run it from ~/Downloads) and simply running it has hijacked these associations.

This is why people hate porting to Mac. Because at some point they need XCode and XCode is horrible.

As someone who has to use xcode from time to time to maintain a number of apps for work. It is my absolute least favourite IDE. Its such a bad experience.

I prefer writing in vscode instead and only using xcode to compile and debug.

Same experience. The 2009 version of Eclipse was more stable than modern XCode. And that’s saying something.

It's a shame too, because it's always seemed like a very cool platform develop for.

I developed some simple macOS apps as fun side-projects back in the early 2010s but then very much switched to web; the tools are a big reason why.

If you told people in 2006 that 20 years later the best open-source IDE would be open-source, web-based and come from Microsoft, they would've thought you're crazy.

Back then Apple had made waves introducing Safari, which was not only great and cross-platform, but had an open-source renderer (WebKit), and JavaScript engine (JSC). Safari was crushing web standards while IE lagged, seemingly trying to purposefully choke the web to stop it from canibalizing Windows software. Apple was betting on web: one of the big features on their brand-new Mac OS 10.4 Tiger was the Dashboard with widgets that were all built with HTML/CSS/JS, and they were shipping a new, free IDE (Dashcode) to build them too.

Mac OS X was heavily marketed for being UNIX vs Microsoft's proprietary and closed Windows NT. They were building Safari and iTunes for Windows, and had just introduced the first Intel Macs; it seemed like they were out to put a fight against a very closed, very walled, and very incompatible Microsoft who had gotten too comfortable with the Wintel and IE monopolies.

Fast-forward two decades, and not only can you now run a native GNU/Linux environment on Windows, but the best IDE out there is web-based and open-source Microsoft software while Apple lags behind on developer experience. They seems to have missed the bus on web technologies too. They went from leading charge with a stellar browser pushing web standards forward, to being an obstacle out of fear Safari might canibalize iOS software.

Apple hasn't gone full early-2000s Microsoft (thankfully) and Microsoft hasn't gone full early-2000s Apple (unfortunately) but times have really changed.

I like to take a few minutes to admire the content underneath/behind my sidebars

Same, I did try to sell native app development to my current project, but some higher up had already decided on React Native at the time.

And I get it, it feels like native app development is a more expensive specialism, and this particular use case is mostly the customer portal but in an app. But I retain the strong opinion that if you as a company are serious about app development, if you want a good app, you need native apps and native app developers.

Especially if you want to be present outside of the confines of your app - widgets, lock screen activities, smart watches, etc all require proper native components, because they come with very tight memory constraints and just loading in React Native and its JS stuff costs you 80% of available memory budget.

Having used Android Studio for work for a few years and used Xcode quite a lot for longer, I find the praise for Android Studio to be puzzling. I would give it "fine" but no way I'd say it is "good". I haven't used it enough compared to Xcode to say if one is better than the other.

I would recommend trying out kilocode as a vscodium extension instead of Cursor. Better pricing and more model options. For me it completely replaced Cursor and couldn't be happier.

Came to say the same thing about Xcode, hehe. Could it be that the best tool is the one you're used to.

> you can't open a project and one of it's dependent swift packages for editing simultaneously

You can. Any local packages are automatically editable in Xcode. Opening two projects referencing the same local package dependency isn't possible however.

Seriously lol do they have Vim mode yet

Used XCode in anger from 2011-2016 to develop an iOS app with several million users and found it to be just as awful and temperamental as others here describe.

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.

I've been using tuist plus codex cli and vscode. only using Xcode for running and debugging. I would love to get rid of xcode entirely. The tuist plus xcode project is a tiny shim - the rest of the app is in spm packages.

Tuist generates the code project from a simple swift confiuration file similar to Package.swift. I don't know why apple can't just throw away the proprietary and ugly Xcode project files and provide a sane build system that would work in any IDE, on the command line, in CI and now with AI agents.

They could open up the instruments format while they are at it for the same reason, do they really gain anything by making it proprietary?

XcodeMCP (Native MCP added in 26.3) Implements this with RenderPreview

RenderPreview: Builds and renders a SwiftUI #Preview, returns snapshot

False dichotomy. Terminal debugging is garbage. The GUI you use for writing code doesn’t have to be the same GUI you use for debugging code.

RemedyBG: https://remedybg.itch.io/remedybg

RadDbg: https://x.com/rfleury/status/1747756219404779845?s=46

I mostly edit code in VSCode. I mostly debug code in VisualStudio. They don’t have to be the same.

I do concede that one tool to rule them all is appealing. But ultimately I work with many different languages so it’s kind of a multi-tool world no matter how you slice it.

> 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

Thanks for clarifying. Since I don’t use the LLM features in Xcode, I’m leaning toward skipping this version.

>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.

You can do the signing in Xcode Cloud. I'm sure with CLI it's possible too

There are command line tools which arguably are part of xcode, but you can drive them from the cli/ssh and don't need to interact with the xcode GUI.

I am doing interactive coding sessions via API. I don't want to see a message that I am over limit to use the best model there is.

But via my Claude Code usage or via the API usage?

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.

"custom versions of Claude"

spray those menu icons everywhere