zlacker

[return to "Xcode 26.3 – Developers can leverage coding agents directly in Xcode"]
1. flohof+o5[view] [source] 2026-02-03 18:24:34
>>davidb+(OP)
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.
◧◩
2. allthe+Kf[view] [source] 2026-02-03 19:02:56
>>flohof+o5
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?

◧◩◪
3. ASalaz+3o[view] [source] 2026-02-03 19:37:56
>>allthe+Kf
> 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.

◧◩◪◨
4. spaced+ry[view] [source] 2026-02-03 20:23:38
>>ASalaz+3o
Honestly, that just sounds like it does things in an unfamiliar (to you) way. That's the flip side of the coin "This means you've learned to work around its shortcomings".

There is no perfect IDE. They all have problems / are inadequate / get in the way. I absolutely loathe IntelliJ IDEA for example, and think Eclipse is needlessly complex (though I'd like their code-indentation/formatting UI to replace the one in Xcode).

Honestly, Xcode gets a lot of bad comments, but it works pretty well for me and the debugging tools are pretty much top-notch if you take the time to learn them.

I started a project on January 5th. Running sloc right now I see:

---------- Result ------------

            Physical :  44454
              Source :  31019
             Comment :  7284
 Single-line comment :  2622
       Block comment :  4662
               Mixed :  210
 Empty block comment :  2
               Empty :  6363
               To Do :  0
Number of files read : 195

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

That's a lot of code in just under a month (and none of it from AI tools), I don't think the IDE is getting in my way.

◧◩◪◨⬒
5. 9dev+HF[view] [source] 2026-02-03 20:58:22
>>spaced+ry
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.
◧◩◪◨⬒⬓
6. spaced+BH[view] [source] 2026-02-03 21:08:38
>>9dev+HF
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...

◧◩◪◨⬒⬓⬔
7. 9dev+GM[view] [source] 2026-02-03 21:36:25
>>spaced+BH
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.

◧◩◪◨⬒⬓⬔⧯
8. spaced+Vf2[view] [source] 2026-02-04 08:54:12
>>9dev+GM
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.

◧◩◪◨⬒⬓⬔⧯▣
9. 9dev+EI2[view] [source] 2026-02-04 12:33:24
>>spaced+Vf2
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.

◧◩◪◨⬒⬓⬔⧯▣▦
10. spaced+Li3[view] [source] 2026-02-04 15:49:57
>>9dev+EI2
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 :)

[go to top]