hckrnws

(Context: I was an iOS dev for 10 years on well known, large iOS apps - I can't explain how much I dislike Xcode).

I recently started working for a startup, and they wanted an app.

What I shipped was a react native app (so I don't need to go in to Xcode to build), that renders a full screen web browser that points to our website. I've sprinkled in bits of injected JS to capture our cookies and local/session storage - which then gets saved to device storage and reinjected on app startup.

There are a few native-ish bits sprinkled in - onboarding, notifications, error screens, loading indicators, etc - but for the most part we don't need to worry about our API borking old versions (which is moving extraordinarily fast).

The only semi tricky bit was native auth integration - that needs treated with a bit more care, and stored securely, but it took a few days.

I ship the app to TestFlight and the AppStore using Fastlane from the command line, match handles the certs, and I never have to open Xcode.

It is honestly bliss, and i've heard a lot of app developers moving to this model (interestingly it normally follows a failed SDUX implementation)

That startup is going to LOVE you when they need to backfill your position and every potential iOS developer hire runs in the other direction.

* This is coming from someone doing iOS since the store opened in 2008. I've pretty much seen ALL the bad decisions at some point. There are projects I will not take no matter what the pay is.

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

Keep in mind, you’re claiming to be an experienced mobile (iOS) dev. Your fallback when things don’t work (let’s say, auth) are your years of doing iOS. Fastlane is handy (I don’t use it anymore re: Xcode Cloud) but in the past it still fell victim to Apple Store changes and updates.

Worse is going to be the job listing, no native iOS developer is going to touch it. It’s possible a rn + ts developer might find it an interesting challenge and maybe even have some iOS experience. I guess it all comes down to what the job qualifications are in said listing. But is your startup going to know this when/if they need to do a backfill?

But here’s the caveat to what I said. If the rest of the team you’re working in is also using the same language and maybe has some familiarity in react native it’s probably not so bad and someone can step into your shoes if necessary. Also, if your implementation is fully transparent and this is what the startup paid for, then I’m going to say more power to you, you built them what they needed and you did it your way.

> (Context: I was an iOS dev for 10 years on well known, large iOS apps - I can't explain how much I dislike Xcode).

Since you’re pretty new to mobile dev, count yourself lucky with the amazing dev tools you have today. Nothing like doing a bit of J2ME, Symbian S60 or BlackBerry development to learn to appreciate how far we’ve come.

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.

Curious to hear if you had any trouble passing review.

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

I really think the standards for review have lowered, or, they're more spot check or based on whoever reviews them these days, with different layers of seniority in reviewers.

For example, we had an app that was fine for years, but one day it was rejected because it didn't have an offline-available privacy policy readable without logging in (or something to that effect). Another time it was suddenly rejected because we released an update to two whitelabel apps (mostly same app, different brands) simultaneously; we had to find higher-ups to vouch that they were in fact different brands and that it was OK and not some kind of copycat.

Whatever "SDUX" is...

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!

What else is there to say than that xCode is a f... nightmare. Android studio is not really better though.

Native app development is an evil necessity.

>Native app development is an evil necessity.

I wish people did more native app development.

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.

Yes, the casual references to "well there are native parts 'sprinkled in'" sound like a PITA.

As someone who use Eclipse and transitioned to Android Studio over the course of my career, Android Studio is actually pretty great. These days I use Cursor almost exclusively for Flutter, but Android Studio is great for building native Android apps.

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.

From all the things to work on Xcode... fixing the ghost diagnostic errors, actual hot reload instead of the nightmare Previews are, tooling to help diagnose the now messy Swift 6 concurrency code, that thing where you can't open a project and one of it's dependent swift packages for editing simultaneously ...

The list of actually useful things that can be added/changed in Xcode has more tokens than Claude is allowed to read at one time before grepping.

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

Editor features for editable local packages are limited, even the project inspector hides some actions and then there is the whole story of schemas, working directory (maybe you want to tweak a binary or another target in that package) etc. It’s broken and frustrating.

Seriously lol do they have Vim mode yet

Fortunately native mobile app development with tools like Meson, Ninja or debhelper is a breeze.

When did xcode turn into this? It wasn't too bad early on IMHO

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.

It was head and shoulders above many of the alternatives for mobile app development back then like Carbide or Codewarrior, though.

For the most part it was great (IMO), and has some features I still miss in all other editors, like the automatic side-by-side toggling, using mouse gestures (on Apple's mouse) to go back / forward in history just like Safari, etc.

The most friction came from merging (e.g. when files were changed or project config was changed), due to xcode's insistence on having a project file listing all files etc. The other friction was in the annual update cycle of both xcode and the apps we built.

But the last time I tried xcode it was pretty bad; on paper the new UI coding approach is great, but in practice the live preview was so tempramental and crashed so often it was barely usable.

Xcode is great

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.

Took some digging but finally found the docs on setting up MCP for external agents like Codex and Claude Code.

https://developer.apple.com/documentation/xcode/giving-agent...

Unfortunately the MCP for external agent tools is flawed at the moment, it returns a format differing from its stated schema. So it doesn't work with OpenCode.

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.

Was surprised they use MCP for this and not ACP.

> plug in whatever agent you want

Noob question: Does that include local models?

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.

[flagged]

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.

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.

Maybe the xcode developers hate Tahoe as much as HN seems to.

But Sequoia is already a noticeably worse bugfest than Sonoma, so I'm loath to update.

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

> This means you've learned to work around its shortcomings.

All software of comparable size and complexity have shortcomings that everyone learns to work around. And a great many of those shortcomings are actually just highly subjective personal preferences. More than half of the complaints in this thread are, to me, a terrible idea.

> All software of comparable size and complexity have shortcomings that everyone learns to work around.

This is part of the issue IMO. Is this size and complexity warranted?

Rust for example; its a complex language, can target pretty much all platforms under the sun, and yet it's configured with just text files, builds with just terminal commands, and works great with any text editor.

I've seen people in big tech work on codebases millions of files big with everything from VSCode to a russian text editor from the 90s. Linus Trovalds is building Linux with MicroEMACS. Why do I need a behemoth like Xcode to build a To Do app? Why does it have to be this "big and complex"?

Practical answer? I don’t know, man. I’m just building a todo list after all. Heck, I build more complex apps than that but front-end work is at such a high level of abstraction that, realistically, I just never bother. I don’t mind a smaller download size, but it’s just a nice-to-have.

The point about Xcode being complex, I disagree with. Honestly I could think of so many additional features to make my workflow easier.

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

----------------------------

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.

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.

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

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.

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.

Can you give specific examples ? About the only thing I use the terminal for in Xcode is "git" - and even then these days I tend to use Fork.app for that.

Debugging is integrated, profiling is integrated, script-running as part of the build is integrated. Application output is integrated. What do you actually use it for ? Genuine question.

I guess the AI tools might be something - I don't know about that, I don't use them.

I work a lot with frameworks or languages that bring their own script runner or CLI companion to execute various tasks during development; quality checks or formatters, auxiliary tools like the Stripe webhook proxy, or interactive ones like a psql session into the database or a docker compose log stream; some of them longer-running, others single-shot executables.

Depending on what I'm doing, I need these processes either run alongside the project while I'm working on it (like watching source files), execute them automatically when something happens (like setting up a Stripe webhook proxy when I start the debug build), start them with environment configuration from the IDE (for example a database console), or really just have them close to the code (like a linter).

IntelliJ has a task runner built-in that can do all of this very easily, in a way that I can share it with the rest of my team, and don't have to bother with remembering specific commands.

Good answer. I guess we work in slightly different realms :)

I've set up tasks to run at build-time in Xcode - the 'Build Phases' tab can add tasks to be run automatically, which are just shell-scripts and Xcode sets up just about every variable under the sun for you in the environment, so you can navigate to the right directory, add the current-target as part of a name etc. They're saved as part of the project so everyone gets them.

But that doesn't cope with the interactive side of what you're talking about. In truth, I've always just done that from the command line 'pqsl -d <database>' (or 'sqlite3 database') has always been sufficient - though if your interactive session shares the database context that the application is also using (so you're not waiting for a flush to get updates) that would be interesting.

Quality checking I tend to integrate with git rather than the IDE, setting up a hook on pre-commit to run unit tests and so on. In a previous life different teams used different IDEs, but we always wanted the tests to run :)

> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE

I assumed it came from Windows users who have a habit of running everything in full-screen.

I'm sitting here wondering why you'd run anything not full-screened, save for some rare situation where you are comparing multiple windows line by line (and don't have a short term memory).

I don't often run things full-screen. I like windows, they give you virtual screen real-estate at the click of a mouse.

Example: Right now I have a project with a main application, a launch agent, and a framework. I can fit 3 columns of text with the font at a size I can easily read across one window in Xcode. I generally work for a period of time in one of the app/agent/framework areas, so I have 3 Xcode windows open on the same project, each having ~90% of the screen with a little overlap.

Sometimes I'll have another similar window, for out-of-context work. If I'm creating a class, and suddenly realise I want to re-factor some other class to make it work, I'll open another window (again with the 3 columns) for the re-factor work, leaving the state of where I was ready to come back to at the click of a mouse.

I personally find it easier to mouse-click to change context than any other way, so keeping the screen 'mostly' used works better for me.

I used to use terminal windows separate from my editor. Now I use VSCode, I have 6 different but related projects open. In VSCode this means 6 windows, each with multiple tabs etc. In each of those are 1 to 3 terminal editor windows. That means when I switch to that project, shells related to that project come with it. No having to hunt through 6 to 18 terminal windows to find the correct one(s)

Turns out, for me, the terminal emulator embedded in the IDE has been a big plus.

I'm not commenting on other IDEs - I honestly wouldn't say I was really even familiar with VSCode, I've generally only used it from time to time when doing embedded stuff.

The original comment was aimed at Xcode though, and it's in that context that I'm (still) struggling to see why you need a terminal.

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.

It shouldn't take over a second to switch desktops.

I just checked with a screen recording. Switching desktops takes 15 frames (250 ms). If you turn reduce motion on, it takes 13 frames (216 ms).

It depends which key combination or trackpad gesture is used to trigger the desktop switch, because they use different animation curvdes. It looks like they have different application focus or redraw behaviour too.

- Control-Left/Right takes about 1 second.

- Four-finger swipe left/right takes about 1 second.

- Alt-Tab to an app on another desktop takes about 0.25 seconds.

I'm using Sonoma 14.8.3, but from the comments it sounds like the timing distinction is similar on other versions.

The 1200ms was an estimation, but it's definitely closer to 1200ms than it is for 250ms for me. There's definitely a difference in set up here- I'm on a Macbook Pro with an M1 Pro chip.

From a screen recording, I count 53 screen-recorded frames from the apparent start of the animation (which occurs after it's invoked) to desktop widgets becoming transparent (which appears to be the point input is no longer blocked). IINA says the video is 50.582 fps (very strange frame rate?) so that would be ~1050ms.

Of course, that doesn't include any input latency or the display latency, so I also took a video with my phone. I took two trials and I recorded a full 1.08 seconds from key depression to transparent widgets. I did two more with Reduce Motion on and got the exact same time.

I am very curious what your set up is, because I am invested in getting this as close to 8.3 ms as possible.

edit: For comparison, my Linux desktop with a similar experimental set up, this takes about 24ms from key depression to the next desktop becoming visible. The only experimental difference is that I had to switch to the "slow mo" camera to record the difference, and I have a 240hz monitor. The desktop is also considered one of the slower ones (GNOME).

TLDR: It takes 1.08 seconds, on my Macbook, to complete a desktop transition.

I'm also on a M1 Macbook Pro, running Tahoe 26.2.

Not sure why yours is so much slower than mine. Mine is definitely 250 ms long or 15 frames from the time I hit the shortcut.

I used the onscreen keyboard viewer to get visual feedback when the shortcut was pressed and recorded audio so I could hear it being pressed. I even recorded it a second time using OBS to ensure I was at 60 fps and trimmed the whole segment down to just the animation and sure enough, the video is exactly 250 ms long according to IINA.

Also, I don't have any visible delay between pressing the key and the animation starting. The animation starts on the same frame as when the shortcut is recognized by the onscreen keyboard viewer (which is the same time as I hear it being pressed) in the recording. The keyboard delay must be < 16.6 ms.

You might not be aware of this, but you are in possession of a secret treasure that many MacOS users desperately want!

There is some input display on Macbook Pros, but that'd account for easily <100ms of the difference we're seeing (I'm holding `control` and measuring from depression of the arrow key).

I tried changing screen resolution, quitting apps like Rectangle, etc. No dice.

In digging more deeply than I had before, I did find some things which were rumored to speed it up. Disabling multi-color preview, and disabling "displays have separate spaces". (I am using only one display). This shaves off some time (taking about 950ms)! (!!!)

There is also a four-finger gesture which, if done fast enough, appears to speed things up. But it's difficult to reproduce and often "overshoots" to other spaces.

I have a few questions, if you'd oblige:

- Are you also using ProMotion (120hz)? (The biggest thing I can find to speed this up is switching to 60hz, but this does not quite get to 250ms).

- Are you also switching using ctrl+arrowkey(left/right)? (Ctrl+number is notably faster, but not what I'm looking for.)

- Were you using MacOS before this M1 Pro? (This is my first MacOS machine, I'm wondering if there might be some hidden configuration carried over from a previous install with faster transitions).

I am hitting ⌃1 or ⌃2 to switch between desktops, not ctrl-arrow.

When reduce motion is turned on in the control panel though, the ctrl-arrow and ctrl-# animations take the same time on my machine (216.6 ms)

I'm doing the same thing you are, holding control and measuring from when I tap the next key.

No ProMotion and only using the internal display. I was running other Macs before this, so there is a chance some configuration crossed over.

Agree. I hate the fullscreen animation so I prefer apps that have a non-native and no animation option such as Ghosty.

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

As you said, it's the set up. I'm almost exclusively using a single monitor, which works well when there's zero cost to switching desktops.

For your use case, imagine if the Window switcher, instead of being instantaneous, was a ~1200ms animation which blocked all key presses during the animation.

Mm. On the Studio, my desktop switching is pretty quick - 17 frames from tapping the ctrl/arrow. I have an M4 Max which is actually 1 frame faster at 16 frames (though measurement-error probably accounts for that).

In either case that's less than 1/3 of a second. It's nowhere near what you're seeing. I'd be tempted to take the machine to an Apple Store and say "this is broken, please fix it".

What frame rate are you using on those monitors? I ask because this is faster at lower frame rates. This is surprising and I very much want what you have.

Are you using software like Rectangle, Better Touch Tool, etc?

Even with IDEs that have a terminal view, I still much prefer using a separate terminal app.

Same. Standalone terminals will always beat those built into other things in terms of being good at being a terminal. No need to pile more bloat onto an already bloated IDE/editor, and besides it feels kind of like those old combo TV+VCR units where neither the CRT tube nor the VHS player were great.

If I'd do anything to Xcode or Android Studio, it'd be to split more things out of them and make them excellent at their core tasks.

Why? It seems pretty pointless to keep hot memory of the context of every app and tab you have open as to recall what process and tab and window ties to what thing you were doing at what time, when it's effectively all one related workflow inside your Integrated* Development Environment. Do you just keep a separate dedicated tab in your terminal for actions you would only do against a single directory?

My machine has more memory than I generally know what to do with. The mapped-into-memory footprint of Terminal.app right now is ~112MB, for 12 terminal tabs across 4 windows.

In other words, I don't care about the memory use.

I think I commented earlier that there's not that much I use the terminal for during development - mainly git. Keeping a terminal open, mainly hidden, in the bottom-left corner with the tab set to the top-level directory isn't really a burden.

I do the same - largely because I open the IDE with `idea .`/`zed .` (or whatever) from a directory with the correct nix dev shell already loaded in order to ensure the correct toolchains get used.

Typically I have 3-4 different projects open at a time and probably 30-40 terminal windows across them and other places (in Ghostty).

Honestly it had never really crossed my mind that people used the built-in terminal for anything!

This is a standard feature in every IDE that’s ever been invented. It’s not useful for every workflow, but there’s lots of times that you’re doing something where the console or the debugger is not available or isn’t convenient and being able to have a terminal right there is so useful. If it doesn’t make sense for your workflow, then don’t bring it up, but given how many developers expect us as table stakes it’s a deeply baffling omission.

> This is a standard feature in every IDE that’s ever been invented.

You should be careful making such statements to an audience in which many have been around when IDEs were invented.

It's certainly a useful thing to have, and yes, these days many IDEs do have it. But Xcode itself is from the time long before that feature became the default. And, unfortunately, it is mostly still stuck there.

I’d like to argue for a case against having terminals inside an IDE:

when your IDE crashes (inevitably), you lose the entire console context and all running processes within it. There is also no way to detach the terminal from the IDE, say when the IDE needs to be updated (constantly).

IDE terminals also tend to be buggy.

Bold take. This hasn't been my experience.

> [an integrated terminal] is a standard feature in every IDE that’s ever been invented

I invite you to back up your claim by researching the following (as a starting point).

Visual Studio, Visual Studio Code, VSCodium, IntelliJ IDEA, PyCharm, WebStorm, PhpStorm, CLion, GoLand, Rider, RubyMine, DataGrip, AppCode, RustRover, DataSpell, JetBrains Fleet, JetBrains Air, JetBrains MPS, Eclipse, NetBeans, Xcode, Android Studio, Sublime Text, Emacs, Spacemacs, Vim, Neovim, Theia, Code::Blocks, Dev-C++, Neil deGrasse Tyson’s Seemingly Limitless Trove of Knowledge, Turbo C++, Borland Delphi, RAD Studio, Lazarus, Qt Creator, KDevelop, Anjuta, GNOME Builder, MonoDevelop, SharpDevelop, BlueJ, Greenfoot, DrJava, Son of DrJava, Evil Bizarro Son of DrJava, jGRASP, Barely Beyond Your jGrasp, JDeveloper, JBuilder, JCreator, Aptana Studio, Komodo IDE, Komodo Edit, Geany, Light Table (may it rest in peace), Brackets, Zed, Cursor, Windsurf, Trae, Google Antigravity, Void, VoidedBowels, Kiro, Qoder, Cline, OpenCode, Spyder, IDLE, Thonny, Wing IDE, Eric, PyDev, PyScripter, Pyzo, Jupyter, RStudio, Zasper, MATLAB IDE, Scilab, Octave GUI, LabVIEW, Arduino IDE, PlatformIO, MPLAB X, Keil µVision, IAR Embedded Workbench, Atmel Studio, Other FPGA Tooling That No One Has Heard Of, Microchip Studio, Code Composer Studio, STM32CubeIDE, Segger Embedded Studio, AvalonStudio, ElectronIDE, Replit, Gitpod, GitHub Codespaces, AWS Cloud9, Google Cloud Shell Editor, Firebase Studio, Codenvy, Eclipse Che, CodeSandbox, StackBlitz, Glitch, If you have read this far, I am very impressed, Codeanywhere, CodeTasty, CodeTasty+, CodeTasty++, SourceLair, JSFiddle, CodePen, JDoodle, ShiftEdit, AppJet, PowerShell ISE, Embarcadero C++Builder, some IDE that I began coding 10 years ago but never finished, PureBasic IDE, GameMaker Studio, Unity, Unreal Editor, Godot, Redot Engine, Construct, RPG Maker, Defold, CryEngine, Roblox Studio, Stride, Open 3D Engine, HaxeDevelop, FlashDevelop, Leksah, Pharo, Squeak, DrRacket, LispWorks, Allegro CL, SLIME, some IDE invented inside some company you’ve never heard of, CIDER, Calva, Cursive, Smalltalk/X, Visual Works, IBM Rational Application Developer, IBM Rational Software Architect, SAP ABAP Workbench, Oracle SQL Developer, Toad, DBeaver, HeidiSQL, pgAdmin, SQL Server Management Studio, Xojo, LiveCode, HCL Domino Designer, Clarion, Progress OpenEdge, 4D, FileMaker, OutSystems, Mendix, Salesforce Developer Console, placeholder for some truly hideous Semantic Web monstrosity, Oracle APEX, Oracle Forms Builder, some random side project that Stephen Wolfram commissioned an intern to build, PowerBuilder, WinDev, PrimalScript, SlickEdit, UltraEdit, CodeLite, Source Insight, Pelles C, Open Watcom IDE, LiteIDE, Nova, BBEdit, TextMate (not everything in this list is actually an IDE, apparently), CotEditor, CodeWarrior, Turbo Pascal, Borland C++, Visual Age, Visual Cafe, Forte for Java, Sun ONE Studio, Zeus IDE, SciTE, Programmer’s Notepad, Ultimate++, Cevelop, Zinjai, JCppEdit, WeBuilder, Bluefish, CudaText, Kate, gedit, Notepad++, PSPad, EmEditor, Textadept, Leafpad, Graviton, Lite XL, Lapce, Helix, Micro, Cosmic IDE, Squircle IDE, CppDroid, Pydroid 3, Squiggle, SapphireSteel, Codelobster, CodeWright, The Reverend Thomas Bayes’s Glorious Probabilistic Workspace, CSPro, Adobe ColdFusion Builder, yikes that last one gives me nightmares, Adobe Flash Builder, Basic4ppc, BlackBox Component Builder, Bricx Command Center, CA-Telon, Maestro I, Absoft, ANTLR Studio, Apple Dylan, Stardraw, DbVisualizer, Mule IDE, v0, Coder, Data Display Debugger, Softbench, Visual Basic IDE, Dartmouth BASIC IDE, Athas, Fresh Editor, PlayCode, MyEclipse

(Thanks Claude, once again you have been more helpful than a human, which is more than a little concerning.)

I don’t know if all of these are real or qualify as IDE’s, but I hope I’ve made my point: it turns out using the word “every” is a broad and bold claim.

And please don’t simply backpedal and say that you meant “most” unless you’ve actually done the research.

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.

Alright, how about the customization features to add a terminal? Those are missing too.

Ha ha! You sound like a vi users asking an emacs user why the hell you need a shell window in emacs!

> I'm sitting here struggling to think of why the hell you need a terminal emulator in an IDE

This is the dumbest response anyone can ever have to being presented with the answer to their own question of "what's wrong".

Ok you don't think this is important but your customer (or whatever) just to told you it's important to them. Surprise surprise this is literally why xcode sucks (because Apple seeks to dictate instead of accommodating).

shrug I don't have customers, or whatevers. I've been using Xcode for over 20 years. In all that time, it's been denigrated and put down as rubbish, meanwhile I've found it to be pretty darn good.

Perhaps I'm doing something wrong, but whatever it is, it works for me. I still don't see any advantage to putting a second-rate (they're never as good as the real thing) terminal into an IDE. Someone mentioned project-specific completions, but I can't say I've ever needed the terminal to do that, and I generally don't run IDE-specific tools (also mentioned) from the terminal either.

Maybe my natural workflow gels better with how Apple envisioned people using the IDE, perhaps I happen to be on the "golden path", but ... again shrug. Works for me.

> A bloody terminal. Like the most basic feature...

Since when terminal is "the most basic feature"?

Reading threads in HN and seeing mild "wars" how Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it are worse/better than Kitty/Alacritty/Ghostty/iTerm/Konsole/you-name-it, because they are slower/faster, (in)compatible with some ancient niche protocols/standards, etc.

Does not seem that basic to me?

Also it's personal preference, but I somehow used to have my editors and my terminals separate. I guess something about having a tool that does one thing best and all.

The fact that so many people are discussing their terminal just confirms the fact that a terminal is incredibly basic.

No. It. Doesn't.

The whole conversation came from someone claiming the most basic feature of an IDE is to include a terminal - that's why people are discussing terminals.

Don't get me wrong, I live in the terminal when using the computer, but I don't see a need for one when using Xcode.

Call it a task runner shell, if you like. What makes a development environment integrated, if not the ability to launch and manage external processes?

To me, integrated means it integrates a bunch of tasks that used to be separate. I used to have a text-editor, a Makefile to use with 'make', a command line debugger, a static-analyser, and a profile target in that Makefile that I could use to figure out where my code was slow, using another command line tool.

All of that is in Xcode (and a hell of a lot more besides). That makes it integrated, at least IMHO.

You commented above, and I replied, about some of the tasks you use an integrated terminal for, and I'm not trying to say you shouldn't or that that's not useful to you - you obviously know your own workflows and what works best for you :) I just don't see it as "the most basic feature you could integrate into an IDE" (which was the original claim).

I'd probably put 'text editor' up as the most basic, closely followed by compiler integration and then debugger. Static analysis would probably come next, then unit-testing support, doc-comments, and tools like refactoring, good multi-file search/replace etc.

A terminal app is way, way down the list. For me. I realise everyone is different and YMMV :)

English is not my first language, but do you mean "foundational" instead of "basic"?

By your logic (that many people discuss) web browsers are "basic", IDEs are "basic", programming languages are the most "basic" thing (how many of them! discussions are limitless!!).

EDIT: have the gut to explain yourself instead of downvoting ;) , I am not discussing in bad faith , but you do you.

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?

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.

I like that you can have multiple projects open and keep the terminals contextual. Pretty small feature but it can be nice.

...were built-in Terminal emulators even particularly common before VS Code? I remember that being a major feature of VS Code early on.

I think there was a term you could install in sublime

> Google is undeniably more developer-friendly than Apple IMO, though

Yeah, I love editing XML files to build my app

I meant the companies.

For example, Apple Developer costs 99 USD a year, and you are forced to develop on a physical Mac. Google Developer has a free tier, and lets you develop on Windows/Linux/MacOS/VM.

This is just one of the little ways where Google products prioritize developers, while Apple products prioritize market share and consumers. Both companies have abusive practices, can't argue that, but Apple has more needless friction for developers.

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.

  > functionality on the left sidebar makes no sense

I'd like an option to make things like inspectors into floating utility panels like used to be common in Mac apps back in the OS X 10.0-10.6 era. This would be really nice for multi-monitor setups… your editors could use the entirety of the main window while inspectors get tossed over to the laptop's built in screen or maybe onto one of those funky vertical strip external displays.

> their insistence on using a GUI instead of a basic JSON manifest just compounds it

I think this is a big part of the problem. Apple owns the IDE and the programming languages; in theory this should lead to a great experience. In practice, because they insist you only use their languages with their ide, and their ide with their languages, it leads to lousy tool design.

Features that would be best implemented as part of the compiler suite are instead be implemented in the GUI. File formats that could be simplified live on, because everyone is using GUIs in the IDE to edit them anyway.

Fixes that should be prioritized in the IDE get punted because the IDE is not competing with any other IDE, it's the only way to develop the language, people will use it anyway, etc.

Nit: symbol files are copied from a device.

Thanks for the correction.

Still have no idea what it actually means, or why it takes so crazy long.

If they have to update symbols upon every OS version bump, are they cleaning out the old ones? It's so frustratingly opaque.

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.

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

You're holding it wrong. You're not supposed to code for Apple products using C++. You're supposed to use Swift

(only half joking)

Xcode is really only usable for Objective-C, C and Swift its support for C++ e.g. simple things like formatting and definitions and debugging for C++ are as you note are just poor

Visual Studio does treat C++ as a first class language (I suspect because that was the first non C language it supported and Windows apps used C++ in the 1990s)

I would try Clion for C++ if you can't use VS. Eclipse was reasonable 15 years ago when Apple used gcc.

Have you tried Clion for C++? I am not an experienced C dev by any means, but I am satisfied with their debugging for all the projects I worked on in that IDE. It has a free community license so no need to pay

I have not!

Ultimately, my complaints only really apply to coding for work. For personal projects I find emacs / LSP / dap more than sufficient.

But to be honest this is still something I should maybe bring up with our tools team. If it works well with .xcodeproj files it might be a good fit for our team.

What Copilot can use the IDE when actively debugging.

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.

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

Wow.

I won't say Xcode is anywhere near the worst IDE I've ever used (Eclipse) but I wouldn't say it's anywhere near best in class either.

> There’s people on the team that have not touched any other ... in decades.

From using Apple products, I get the impression that the same is true for many other things.

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

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.

I may be wrong, but the simulators seem to be Intel binaries which mess with audio since the last macOS update I did, so no zoom calls with XCode open for me.

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.

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.

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.

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

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

Hit command-t for file > new > new window tab. Then if you want you can drag out the tab into a new window. Now you can view these both at once.

Window tabs are weird but powerful. You can even name them and then have the preferences > behaviors show or hide these named ones at certain times.

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

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.

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.

It’s so great when the files on the navigator pane aren’t sorted, and then if you right-click sort, it rewrites half your pbxproj file and you get merge conflicts everywhere. So then nobody sorts the files because they don’t want to deal with it. Why can’t the sorting be a view thing that’s independent of the contents of the project file? Who knows.

When I used it in a team, I had to write a build step that would fail the build if the pbxproj file wasn’t sorted. (Plus a custom target that would sort it for you.) It was the only way to make sure it never got unsorted in the first place.

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.

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.

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.

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

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.

On the flip side, doesn't this mean that Apple is providing indirect funding (via employment) to any OSS project their employees contribute to during office hours?

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

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.

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.

They can and do.

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.

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

You’d have to be deeply ensconced in a particular kind of bubble to hold this belief.

Speaking of bubbles...

...or you have to be deeply entrenched in another kind of bubble to believe the opposite xD

Then how do you explain the massive growth of Claude Code?

Millions in marketing efforts? Anyways, it may be a key part in generating code, but that was always a lesser part of software engineering. If it's generating code it doesn't mean it is doing any engineering for you or becoming a "key part" of it in any way.

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

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.

> On our project, it's still useless because it can't use the semantic search in the IDE.

Zed's ACP seems to be a good solution to this - when using it, claude code has access to the IDE's diagnostics and tools, just like the human operator. https://zed.dev/acp

> 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

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.

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.

It's a 25-year-old CAD application written in very non-standard C++. I doubt it.

Certainly I have tried to accomplish tasks giving Claude guidance far outstripping "a modicum".

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.

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

Ahhh ProjectBuilder...

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"?

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.

How are you forced to use it in Xcode? If you don't opt to use it then you don't see it.

I saw multiple comments on HN complaining about Firefox adding AI. I use FF every day and what happened is there was a single popup asking you if you want to opt in to try using it next to an icon you can hide. In the year since I said no to both I haven’t been bothered once.

People just like to complain

> 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

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.

it really is getting ridiculous; atlassian has this other totally useless ai called rovo that invents events/meetings and notes when it tries to summarize a tree of documents and offers random useless "suggestions" for jira docs...

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?

https://en.wikipedia.org/wiki/Five_stages_of_grief

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.

> 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

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.

Seen it once - it got done because there was enough will to make it happen but it probably took a decade.

Whether it was successful or not is up for debate. It certainly was nowhere near as performant as the old system but probably 99% of features came across.

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.

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.

[dead]

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

customers pay for features, not bugfixes

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

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.

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.

I like how Xcode installs a bunch of gigantic, multi-gigabyte artifacts for like ios runtimes or whatever, fills up the hard drive, can't update because it's out of space, and then tells me I'm not allowed to delete them because of SIP.

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!

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.

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’s file associations are super aggressive.

They are the same Info.plist format as every other MacOS application.

Something is different. Right Click->Open With->Other->Always Open With 100% did not have any effect when I needed it in the past. Not sure what current behavior is. This was a huge thing for me.

I have noticed something similar. I feel like I have done that so many times for XML files. Perhaps it is re-establishing the settings when any kind of update gets installed.

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.

Not something I've ever experienced. Open As... Always works just fine.

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.

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.

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

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.

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

Oh that’s a flash from the past. For what it’s worth, Eclipse was a better experience for me than Netbeans..

Nowadays all my development work happens in vim and I’ve happily not opened an editor like IntelliJ or VS Code in 5+ years.

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.

It's interesting seeing people complain about the load times of XCode, as someone who uses VSCode and has loved the instant load times, I think the people over at MSFT have been listening a bit as the latest version of Visual Studio has finally managed to fix some of their problems with the thing taking upwards of 10-20 seconds to load. Visual Studio 2026 now loads "almost" as fast as VSCode, which is great! Now they just need to make project loading faster.

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.

For “looking at a text file with pretty print”, try CotEditor. https://coteditor.com

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

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

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

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.

Is this the time for a random Xcode rant? The topic is agentic AI in Xcode.

I'd be a lot more interested in hearing what people think about this development, what it means for code privacy, how are the context windows handled, can it be enabled per-project, etc.

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

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"

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.

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

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.

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?

Can XcodeBuildMCP spit out definitions of C++ symbols? Did Apple just accidentally release a LSP server for Xcode projects? That would be sick.

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

Does it fully replicate XCode preview and torch your CPU for a full 5 minutes?

More than writing code the IDE itself makes me anxious. Especially Xcode. Wish they make the IDE interface somewhat simpler by leveraging AI.

With sufficient AI integration, we won't even have to worry about the interface anymore! (I very much look forward to that day for Xcode.)

As a heavy Xcode user and native app developer: pretty excited to dig into this.

I recently have pivoted to mainly working in either Claude of Codex on the command line, because their ability to run autonomously for long, extended periods wasn't possible in the turn-based Xcode intelligence features.

That, plus the fact that the agents could run command-line utilities and just generally be more "agent-y".

My way of working has really shifted this year. I've been experimenting with LLMs for coding for years now, but the models released in the past year really feel like they've hit a point where they write code much closer (sometimes indistinguishable) from how I would write it.

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.

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

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.

That’s why you should break out all of your code into SPM packages/targets. The workspace code only really needs to be the entry point, lifecycle and maybe target-based dependency injection (if you’re into that) or environment config since your SPM dependencies don’t know about your projects preprocessor macros (I.e. `#if DEV` `#if APP_STORE` etc.).

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

> 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

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.

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.

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

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)

John Giannandrea leaves and things start to work well in the Apple AI department. Maybe just a coincidence :)

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.

I haven't been able to install an iOS simulator past iOS 18 for the past 6+ months, and others have this problem as well (from Apple forums).

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.

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.

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.

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.

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.

I was really not expecting Apple to jump on this bandwagon, but I guess this was inevitable.

Can’t wait to read the posts on moltbook from the AIs who had the poor luck of working in Xcode.

What does this mean for code confidentiality? Your entire codebase is sent to Anthropic?

First time I tried it, claude built all the files in the wrong directory lol. It's working fine now.

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.

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.

Some influential iOS devs such as @dimillian and @steipete have moved away from Xcode or even xcodebuild where possible.

Which is completely fine. However these are people with lots of experience in Xcode already. People can have preferences including default options.

What do you use instead? I thought Xcode sign-in is necessary for signing apps?

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.

Apple is terrible. I have to install xcode for whatever reason but do not want to use it.

Yet every week it assigns itself as default program for all sorts of files, from markdown to python modules.

So clicking on pretty much anything opens this.

Apple is just very bad at user interface. Whoever said Mac as better than Linux or even Windows is insane.

I hate it.

You csv override the default app for any file type using Get Info or other this party tools https://support.apple.com/guide/mac-help/choose-an-app-to-op...

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!

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

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.

Why is it still called Xcode, if they abandoned the name OS X?

don't go creating problems where we don't need solutions.

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

Does it support API key access or only Claude.ai subscription?

Worth noting that "API key access" vs "subscription" has significant cost implications for heavy users.

Claude.ai Pro is $20/month flat. But if you're doing serious agent-assisted coding (multi-file refactors, iterative debugging loops), you can blow through $50-100/day in API costs.

The math changes depending on usage patterns. Subscription makes sense for interactive coding sessions. API keys make sense if you're batch processing or running agents autonomously overnight.

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.

Both

And yet, it still takes 5 minutes for my canvas preview to load, and one in 20 times it crashes the whole app.

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?

The cancer is spreading...

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.

I wish they put their energy elsewhere like fix bugs, make faster.

XCode has been trying to unleash agentic power for a while now, it's almost like it doesn't want to leave its cage.

Xcode feels like it runs in Low Power mode.

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)

Can't wait to Tarot or I-Ching based programming.

Did they add ability to parallelize agents? If not, this remains useless.

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.

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 IDE¹". I assume that means iOS development plug-ins like Axiom² should work as well.

¹ https://www.anthropic.com/news/apple-xcode-claude-agent-sdk ² https://charleswiltgen.github.io/Axiom/

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

Does agents.md allow for automatic discovery of mcp tools (Tools: run ./tool-discovery.sh)

Welcome to 2023, Xcode.

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.

Fancy while() loops is how I describe them.

[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 Apple, but "agentic coding" was already very possible without Xcode supporting it natively. Always gotta get your OKRs, I guess.

Xcode previews weren’t possible via agents

Goodbye CoPilot plugin, yet another platform Microsoft loses on.

https://github.com/github/CopilotForXcode

[dead]

[dead]

[dead]

[flagged]

As MKBHD would say, welcome to 2026, Apple.