Live data from Hacker News

Xcode 26.3 – Developers can leverage coding agents directly in Xcode

apple.com

71–80 of 348 posts

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#71

Earlier quoted context omitted.

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?

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 s…

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.

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#73
post #26

Earlier quoted context omitted.

True that Xcode needs yet another rebuild from scratch. If they forked it and abandoned the old project file and went with a swift first approach, could work. However adding support for Claude is still a huge win. Could lead the way to making the transition to a sane IDE possible / reasonable. This would require leadership that’s completely absent at the company.

> If they forked it and abandoned the old project file and went with a swift first approach, could work. Ever attempted this before at a large company and had success with it? I think I can count four times so far in ~15 years where people attempted to rewrite something medium/large-scale from scratch around me, was a success once, although scope was drastically cut at the end so almost a stretch to call it a success…

In this particular case they just need to release a tool that properly generates compile_commands.json and .clangd from a .xcodeproj.

Boom! emacs is the IDE now. Bonuses all around.

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#74

Earlier quoted context omitted.

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…

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.

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#75

When do you actually need to open Xcode if you have XcodeBuildMCP [0]? I haven't opened Xcode in months. My terminal: Claude writes code. build_sim. launch_app_sim. screenshot describe_ui. What still requires Xcode: Instruments profiling, Signing/provisioning For UI iteration, describe_ui returning the accessibility tree might actually be more useful to an agent than a preview screenshot.

I still open Xcode for every branch after having Claude do an initial implementation, to review the changes using its version editor, step through code using the IDE’s various code navigation features, and build/run to manually validate the changes. I do have claude analyze and test, though.

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#76

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.

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#77

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?

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

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#78

When do you actually need to open Xcode if you have XcodeBuildMCP [0]? I haven't opened Xcode in months. My terminal: Claude writes code. build_sim. launch_app_sim. screenshot describe_ui. What still requires Xcode: Instruments profiling, Signing/provisioning For UI iteration, describe_ui returning the accessibility tree might actually be more useful to an agent than a preview screenshot.

I still 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

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#79

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

Re: Xcode 26.3 – Developers can leverage coding agents directly in Xcode

#80

Earlier quoted context omitted.

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.
Post reply on HN