6 ms·

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 hyp

Building castles in the sky while the foundation is rotting away :/ Xcode really needs a couple of years of pure bugfix and optimization releases instead of hype-chasing.

emchammer 9mo ago
A lot of macOS needs that. There are some terrific ideas under the hood, but it’s as if people left halfway through implementing them.
- embedding-shape 9mo ago
  It's a damn shame, the hardware is pretty amazing and I wish they just had like one person who cared about Linux working at Apple and then make a small promise to not rugpull Linux users.
  - ndiddy 9mo ago
    I think one thing that shows Apple's position towards open source in general is that they don't allow their employees to work on open source projects in their own time and using their own equipment. Before anyone brings up that California labor code provision, it has a carve-out for "activities that relate to the employer's business". Since Apple is big enough and has their fingers in enough pies that they can credibly say that virtually any open source projects developed by Apple employees are related to their business, I would be wary about fighting them in court over this.
    - jajuuka 9mo ago
      I don't think this is it. I can only find one tweet from an Apple employee who said that they can't work on OSS and was looking for new maintainers. I am not sold that this is the whole truth. I think the bigger issue is contributing to OSS for putting Linux on a Macbook for example could be considered leaking company secrets since you would have access to internals. I find it hard to believe that Apple would go after someone for making a open source calculator app.
      - dylan604 9mo ago
        I worked for a non-FAANG company in California and the onboarding/exit process about side projects was one of the most annoying thing I've had to deal with. As far as why would silicon valley peeps put up with it...money. Big corps are worried that you will implement something you learned while on the job into one of your side hustles. Not defending it, just stating a bit of reasoning.
      - saagarjha 9mo ago
        They can and do.
    - 9dev 9mo ago
      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??
    - the_other 9mo ago
      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?
briandw 9mo ago
True that Xcode needs yet another rebuild from scratch. If they forked it and abandoned the old project file and went with a swift first approach, could work. However adding support for Claude is still a huge win. Could lead the way to making the transition to a sane IDE possible / reasonable. This would require leadership that’s completely absent at the company.
- embedding-shape 9mo ago
  > If they forked it and abandoned the old project file and went with a swift first approach, could work. Ever attempted this before at a large company and had success with it? I think I can count four times so far in ~15 years where people attempted to rewrite something medium/large-scale from scratch around me, was a success once, although scope was drastically cut at the end so almost a stretch to call it a success.
  - neutronicus 9mo ago
    In this particular case they just need to release a tool that properly generates compile_commands.json and .clangd from a .xcodeproj. Boom! emacs is the IDE now. Bonuses all around.
  - briandw 9mo ago
    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.
  - zenlot 9mo ago
    [dead]
  - jamesfinlayson 9mo ago
    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.
brokencode 9mo ago
Idk, I feel like these coding assistant features aren’t that hard to add, but can provide a lot of value to developers. Most or all popular IDEs now support similar features. I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.
- WillAdams 9mo ago
  Yeah, I'd like to see another OS release like to Snow Leopard (10.6.x) which had as a prime focus simplification and so forth w/o adding many (any?) features.
egorfine 9mo ago
Bugfixes won't make shareholders happy while shoving AI down our throats will.
- XenophileJKO 9mo ago
  So you're still in the anger phase?
  - Banditoz 9mo ago
    What does that mean?
    - layer8 9mo ago
      https://en.wikipedia.org/wiki/Five_stages_of_grief https://en.wikipedia.org/wiki/Five_stages_of_grief
  - egorfine 9mo ago
    Well yes but actually no. For the last ~15 years or so I only use Xcode on the command line sporadically. Prior to that I had to endure the full Xcode experience. I actually liked it between crashes!
- doug_durham 9mo ago
  In what way is "AI being shoved down you throat"? Did you think that SwiftUI was shoved down your throat? Did you think that CoreData was shoved down your throat. Perhaps develop a more nuanced critique.
  - egorfine 9mo ago
    > 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.
gwking 9mo ago
For the record, I started using Xcode before it was called that and people have said this almost every year since. As I recall there was a big hit to its quality when they converted it to obj-c’s short lived garbage collection, and it felt like it never got back to reliable after that.
- Ryder123 9mo ago
  Ahhh ProjectBuilder...
- andrekandre 9mo ago
  > converted it to obj-c’s short lived garbage collection that was around xcode 4 iirc, that was when interface builder was ducktaped (or maybe i should say intermixed) with xcode (née project builder) to disastrous results in terms of performance... its never really recovered imo...
cosmic_cheese 9mo ago
A full rebuild might be throwing out the baby with the bath water. As someone who’s been using it since it was known as Project Builder, bugs seem mostly concentrated in the XIB/Storyboard editor (formerly known as a Interface Builder), SwiftUI live preview, and SwiftPM package resolve. In a project with code-only UIKit, only a smattering of SwiftUI for small components, and minimal dependencies, Xcode isn’t too bad of an experience and I’d say comparable to and in some ways better than Android Studio (that localization XML editor, not mention Gradle… ugh).
- sunnybeetroot 9mo ago
  Refactoring works half the time, Android Studio is much more stable for basic developer tooling.
  - cosmic_cheese 9mo ago
    I've not found Android Studio to be particularly amazing for those kinds of features either. Sometimes they work, sometimes they half-work, and on occasion I've had them do the wrong thing entirely. A lot of refactoring work across both platforms ends up being manual one way or another.
  - ZenDroid 9mo ago
    Because it's developed by JetBrains (with Google contributions), a company whose main business is writing really good IDEs. Apple on contrary is a hardware company that happens to build software. If they had delegated the XCode development to JetBrains, we would have had a great IDE for macOS/iOS development too. AppCode was damn good with zero support from Apple side, and despite the fact that JetBrains always needed to catch-up with Apple's breaking changes.
allthetime 9mo ago
Honest question. I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points. They are definitely fixing bugs. I make software for iOS, macOS, car play, and apple watch. Sure sometimes I've got to reset or clear a cache, but this has never stopped my day. What is so horrible about XCode?
- flohofwoe 9mo ago
  My pain points are mostly in the CPU debugger (since I'm not using much of the actual "IDE features" of Xcode except the regular edit-compile-debug loop anyway. Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI? This problem seems to go back to the ancient times, but it gets worse and worse the bloatier macOS UI processes become (e.g. the more system frameworks they load at start). The debugger variable view panel is so bare bones that it looks like it's ripped out straight from an 80's home computer monitor program. When debug-stepping, the debugger frontend is quite often stuck for 10s of seconds at completely unpredictable places waiting for the debugger to respond (it feels like a timeout). Step-debugging in general feels sluggish even compared to VSCode with lldb. For comparison, VS2026 isn't exactly a lightweight IDE either, but debugging sessions start instantly, debug-stepping is immediate, and the CPU debugger is much more feature rich than Xcode's. While in Xcode, everything feels like it's been added as a checklist item, but then never actually used by the Xcode team (I do wonder what they're using to develop Xcode, I doubt that they are dogfooding their own work). The one good and useful thing about Xcode is the Metal debugger though.
  - neutronicus 9mo ago
    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.
ddalex 9mo ago
> Xcode really needs a couple of years of pure bugfix Claude code 8 hours later: It's done, mate!
- walt_grata 9mo ago
  Come on Claude, making it not start isn't the same as fixing the bugs
- deleted 9mo ago
  [deleted]
markbao 9mo ago
This is not hype-chasing. AI is a key part of software engineering now. For this to be absent from Xcode would be an existential risk for the future of the product.
- eptcyka 9mo ago
  Claude Code from the terminal is servicable enough. Yet I cannot open the same project from different versions of Xcode without some manual finnagling. Xcode is at no existential risk for it is the only tool you are allowed to use to reach your audience on the app store. Don’t be ridiculous. The reason Xcode is as broken as it is today is because of the same exact reason. The developer experience need not be great, as long as you can coax the trash fire of a toolchain to upload a signed app to AppStoreConnect, there is 0 incentive for Apple to put any time into the tool.
  - neutronicus 9mo ago
    For a certain-size project it really is not. Single files in our codebase already blow the Copilot query token limit. Great, Anthropic taught Claude to grep. On our project, it's still useless because it can't use the semantic search in the IDE.
    - gbalduzzi 9mo ago
      > Single files in our codebase already blow the Copilot query token limit. This tells more about your code quality that about copilot, and I'm not a fan of copilot
      - neutronicus 9mo ago
        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.
josteink 9mo ago
> 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.
deleted 9mo ago
[deleted]
skirge 9mo ago
customers pay for features, not bugfixes

Building castles in the sky while the foundation is rotting away :/ Xcode really needs a couple of years of pure bugfix and optimization releases instead of hype-chasing.

emchammer 9mo ago

A lot of macOS needs that. There are some terrific ideas under the hood, but it’s as if people left halfway through implementing them.

embedding-shape 9mo ago
It's a damn shame, the hardware is pretty amazing and I wish they just had like one person who cared about Linux working at Apple and then make a small promise to not rugpull Linux users.
- ndiddy 9mo ago
  I think one thing that shows Apple's position towards open source in general is that they don't allow their employees to work on open source projects in their own time and using their own equipment. Before anyone brings up that California labor code provision, it has a carve-out for "activities that relate to the employer's business". Since Apple is big enough and has their fingers in enough pies that they can credibly say that virtually any open source projects developed by Apple employees are related to their business, I would be wary about fighting them in court over this.
  - jajuuka 9mo ago
    I don't think this is it. I can only find one tweet from an Apple employee who said that they can't work on OSS and was looking for new maintainers. I am not sold that this is the whole truth. I think the bigger issue is contributing to OSS for putting Linux on a Macbook for example could be considered leaking company secrets since you would have access to internals. I find it hard to believe that Apple would go after someone for making a open source calculator app.
    - dylan604 9mo ago
      I worked for a non-FAANG company in California and the onboarding/exit process about side projects was one of the most annoying thing I've had to deal with. As far as why would silicon valley peeps put up with it...money. Big corps are worried that you will implement something you learned while on the job into one of your side hustles. Not defending it, just stating a bit of reasoning.
    - saagarjha 9mo ago
      They can and do.
  - 9dev 9mo ago
    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??
  - the_other 9mo ago
    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?

briandw 9mo ago

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

embedding-shape 9mo ago
> If they forked it and abandoned the old project file and went with a swift first approach, could work. Ever attempted this before at a large company and had success with it? I think I can count four times so far in ~15 years where people attempted to rewrite something medium/large-scale from scratch around me, was a success once, although scope was drastically cut at the end so almost a stretch to call it a success.
- neutronicus 9mo ago
  In this particular case they just need to release a tool that properly generates compile_commands.json and .clangd from a .xcodeproj. Boom! emacs is the IDE now. Bonuses all around.
- briandw 9mo ago
  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.
- zenlot 9mo ago
  [dead]
- jamesfinlayson 9mo ago
  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.

brokencode 9mo ago

Idk, I feel like these coding assistant features aren’t that hard to add, but can provide a lot of value to developers. Most or all popular IDEs now support similar features. I don’t disagree that Apple could use a major focus on bug fixing across their platforms right now though.

WillAdams 9mo ago
Yeah, I'd like to see another OS release like to Snow Leopard (10.6.x) which had as a prime focus simplification and so forth w/o adding many (any?) features.

egorfine 9mo ago

Bugfixes won't make shareholders happy while shoving AI down our throats will.

XenophileJKO 9mo ago
So you're still in the anger phase?
- Banditoz 9mo ago
  What does that mean?
  - layer8 9mo ago
    https://en.wikipedia.org/wiki/Five_stages_of_grief https://en.wikipedia.org/wiki/Five_stages_of_grief
- egorfine 9mo ago
  Well yes but actually no. For the last ~15 years or so I only use Xcode on the command line sporadically. Prior to that I had to endure the full Xcode experience. I actually liked it between crashes!
doug_durham 9mo ago
In what way is "AI being shoved down you throat"? Did you think that SwiftUI was shoved down your throat? Did you think that CoreData was shoved down your throat. Perhaps develop a more nuanced critique.
- egorfine 9mo ago
  > 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.

gwking 9mo ago

For the record, I started using Xcode before it was called that and people have said this almost every year since. As I recall there was a big hit to its quality when they converted it to obj-c’s short lived garbage collection, and it felt like it never got back to reliable after that.

Ryder123 9mo ago
Ahhh ProjectBuilder...
andrekandre 9mo ago
> converted it to obj-c’s short lived garbage collection that was around xcode 4 iirc, that was when interface builder was ducktaped (or maybe i should say intermixed) with xcode (née project builder) to disastrous results in terms of performance... its never really recovered imo...

cosmic_cheese 9mo ago

A full rebuild might be throwing out the baby with the bath water. As someone who’s been using it since it was known as Project Builder, bugs seem mostly concentrated in the XIB/Storyboard editor (formerly known as a Interface Builder), SwiftUI live preview, and SwiftPM package resolve. In a project with code-only UIKit, only a smattering of SwiftUI for small components, and minimal dependencies, Xcode isn’t too bad of an experience and I’d say comparable to and in some ways better than Android Studio (that localization XML editor, not mention Gradle… ugh).

sunnybeetroot 9mo ago
Refactoring works half the time, Android Studio is much more stable for basic developer tooling.
- cosmic_cheese 9mo ago
  I've not found Android Studio to be particularly amazing for those kinds of features either. Sometimes they work, sometimes they half-work, and on occasion I've had them do the wrong thing entirely. A lot of refactoring work across both platforms ends up being manual one way or another.
- ZenDroid 9mo ago
  Because it's developed by JetBrains (with Google contributions), a company whose main business is writing really good IDEs. Apple on contrary is a hardware company that happens to build software. If they had delegated the XCode development to JetBrains, we would have had a great IDE for macOS/iOS development too. AppCode was damn good with zero support from Apple side, and despite the fact that JetBrains always needed to catch-up with Apple's breaking changes.

allthetime 9mo ago

Honest question. I've been using XCode for 10 years. For me, it's only improved and I don't have any real pain points. They are definitely fixing bugs. I make software for iOS, macOS, car play, and apple watch. Sure sometimes I've got to reset or clear a cache, but this has never stopped my day. What is so horrible about XCode?

flohofwoe 9mo ago
My pain points are mostly in the CPU debugger (since I'm not using much of the actual "IDE features" of Xcode except the regular edit-compile-debug loop anyway. Starting a 'cold' debug session into a UI application may take 10-ish seconds until applicationDidFinishLaunching is reached, and most of that time seems to be spent with loading the symbols for hundreds of framework DLLs which are loaded during application start (which I never even need because I can't step into system frameworks anyway) - and seriously, why are there even hundreds of system DLLs in a more or less hello-world-style Metal application with minimal UI? This problem seems to go back to the ancient times, but it gets worse and worse the bloatier macOS UI processes become (e.g. the more system frameworks they load at start). The debugger variable view panel is so bare bones that it looks like it's ripped out straight from an 80's home computer monitor program. When debug-stepping, the debugger frontend is quite often stuck for 10s of seconds at completely unpredictable places waiting for the debugger to respond (it feels like a timeout). Step-debugging in general feels sluggish even compared to VSCode with lldb. For comparison, VS2026 isn't exactly a lightweight IDE either, but debugging sessions start instantly, debug-stepping is immediate, and the CPU debugger is much more feature rich than Xcode's. While in Xcode, everything feels like it's been added as a checklist item, but then never actually used by the Xcode team (I do wonder what they're using to develop Xcode, I doubt that they are dogfooding their own work). The one good and useful thing about Xcode is the Metal debugger though.
- neutronicus 9mo ago
  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.

ddalex 9mo ago

> Xcode really needs a couple of years of pure bugfix Claude code 8 hours later: It's done, mate!

walt_grata 9mo ago
Come on Claude, making it not start isn't the same as fixing the bugs
deleted 9mo ago
[deleted]

markbao 9mo ago

This is not hype-chasing. AI is a key part of software engineering now. For this to be absent from Xcode would be an existential risk for the future of the product.

eptcyka 9mo ago
Claude Code from the terminal is servicable enough. Yet I cannot open the same project from different versions of Xcode without some manual finnagling. Xcode is at no existential risk for it is the only tool you are allowed to use to reach your audience on the app store. Don’t be ridiculous. The reason Xcode is as broken as it is today is because of the same exact reason. The developer experience need not be great, as long as you can coax the trash fire of a toolchain to upload a signed app to AppStoreConnect, there is 0 incentive for Apple to put any time into the tool.
- neutronicus 9mo ago
  For a certain-size project it really is not. Single files in our codebase already blow the Copilot query token limit. Great, Anthropic taught Claude to grep. On our project, it's still useless because it can't use the semantic search in the IDE.
  - gbalduzzi 9mo ago
    > Single files in our codebase already blow the Copilot query token limit. This tells more about your code quality that about copilot, and I'm not a fan of copilot
    - neutronicus 9mo ago
      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.

josteink 9mo ago

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

deleted 9mo ago

[deleted]

skirge 9mo ago

customers pay for features, not bugfixes