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

▲ spacedcowboy 3 hours ago | parent [-]

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.

▲

9dev 3 hours ago | parent [-]

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.

▲

spacedcowboy 3 hours ago | parent | next [-]

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

▲

socalgal2 10 minutes ago | parent | next [-]

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.

▲

9dev 2 hours ago | parent | prev | next [-]

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.

▲

rob 2 hours ago | parent | prev | next [-]

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.

▲

lynndotpy an hour ago | parent | prev | next [-]

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.

▲

spacedcowboy an hour ago | parent | next [-]

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

	▲	lynndotpy an hour ago \| parent [-]
		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.

▲

Aloisius 44 minutes ago | parent | prev [-]

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

▲

zamadatix 2 hours ago | parent | prev | next [-]

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.

▲

timtimmy 3 hours ago | parent | prev | next [-]

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

▲

DonHopkins 2 hours ago | parent | prev [-]

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

▲

FranklinJabar 2 hours ago | parent | prev [-]

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?

	▲	9dev 2 hours ago \| parent [-]
		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.