For a long time I thought Visual Studio was probably better at coding in C++ than Xcode, mostly based on anecdotal evidence. I have now worked with Xcode for more than a year and can root my opinion in some concrete differences.

I’m undoubtedly biased given my vastly longer exposure to Visual Studio and I reckon Xcode does better with Swift/SwiftUI, but C++ is the language I’ve had to use, hence its context for comparison.

A thoroughly objective comparison of something as complex as an Integrated Development Environment (IDE) is hard. Very hard. Not just because previous experience will heavily bias the user, but also because IDEs themselves can differ in both subtle and significant ways making a direct comparison the stuff of nightmares. I say this in order to forcefully add a bit of self-inflicted salt in the opinions I present below. That being said, I stand by my surprise and disappointment when I ran into the following short-comings while using Xcode.

Apart from the first and most egregious short-coming, the other four issues apply to working with any language in Xcode. But again, since I work in C++, that’s the context the critique applies to.

Five short-comings

1. Misleading integrated debugging

We’re starting the show with a show stopper: Xcode can display misleading debugging information when inspecting variables.

Imagine you’ve written this career-enhancing code, iterating over a hypothetical image while keeping a 2D vector in mind:

Vec2 a_point = Point(444.5f, 555.5f);

for (int y = 0; y < 10; ++y)
{
   for (int x = 0; x < 10; ++x)
   {
      float complicated_equation = a_point.x + a_point.y;
   }
}

Now imagine you need to debug this operation, because despite being an obvious code guru, a rare bug has snuck in. You want to inspect what a_point.x is, so you hover over it.

What will Xcode do?

Xcode will display the value of the image iterating x variable! NOT the x co-ordinate of the 2D point struct.

Mind boggling. Just see this GIF demonstration:

Granted, once you’re aware of this quirk, it’s not hard to work around. But when I first encountered this ridiculous behavior, I was genuinely fooled into thinking somehow my variables were not being set properly, or the debugging symbols were stale, or something even more obscure.

It’s also not hard to guess how this behavior comes to pass. Xcode’s logic for attributing values to variable names is simple, so the point structure sharing the exact same name as the looping variable confuses it.

Nevertheless, it is bad. It’d better if Xcode didn’t display anything at all when hovering over the point’s x.

And yes, this still applies to Xcode 26.3.

2. Limited tab support

Xcode’s poor tab support feels like a design decree from on high:

Thou IDE shalt offer naught but a single line of tabs.

I simply don’t understand this insistence in the face of so many viable alternatives. Working in large-code bases can easily lead to having ~10 files open simultanously, and while I’m not claiming to have them all in mind at any given time, it’s really useful to quickly pick which I want to see next from this set of ~10.

Let’s see how some of Xcode’s competitors fare.

Visual Studio offers numerous ways to navigate and manage your open file tabs:

• A drop-down menu to switch to any open tab.
• Pinning enough open tabs forces Visual Studio to reveal more tabs on a new row below.
• Using your mouse-wheel on the tabs toggles between multi-row display.
• Hot keys

VsCode and CLion have a tabs section on the left-hand side, which lists every open file. You can also use the mouse-wheel to scroll through the horizontal tab display:

And Xcode?

A single tab that eventually disappears beyond other GUI elements. Although it can be scrolled through via the mouse-wheel:

So what if you’ve opened too many tabs to fit on a single line and want to see all the files you’ve previously opened, i.e. to get an overview of all 10 files currently open?

To the best of my knowledge, you can’t. I wish I was kidding. I reckon multiple tabs would break one of Apple’s many design axioms, but why in the world there isn’t a down-arrow to reveal this arcane knowledge, or some equivalent, is beyond me. Note that the conveniently adjacent left/right arrow buttons do not switch left and right between tabs, but instead go back and forward through previous tab selections. Something we’ll revisit in a bit.

There are more options to navigate files, e.g. shift + command + o, but again, this still doesn’t show you the collection of files you’ve previously opened.

In other words, with Xcode you’re left to either scroll through or hotkey left/right through the single line of tabs to navigate a collection of open files.

3. No context aware indentation

Yes, there are ways to avoid ever needing context aware indentation, such as automatic linting. But you may find yourself in a code-base that hasn’t (yet) been linted and you’re on the clock to finish a re-factor. You also don’t want to mix in formatting changes for the entire file you’re editing, along-side the re-factor you’re working on.

Both Visual Studio and VsCode will happily keep the indentation for the block of code you’re working in.

Xcode, in my experience, will insist on applying its globally set indentation level no matter the file or context. You can force a group of files into a different manually set indentation. This will – of course – reset whenever you make new Xcode project files using CMake.

Some people will argue that this enforces code cleanliness. Yep. It does. But it does so in a needlessly strict manner. I don’t want to have my habits improved by forceful inconvenience. I’d prefer an IDE that flexibly handles common code scenarios and leaves me in the driver seat to decide when it’s time to clean up poorly indented code.

4. Full-path, reveal thyself

I often have two clones of the same repository checked out.

Why?

Because I’ll be working on a re-factor in clone A, and possibly check outputs against an earlier version in clone B. Another common use-case is to interrupt my work in clone A to complete a code review for a different branch in the same repository in clone B.

Given this situation, it’s nice to be able to perform a sanity check in the IDE checking the full path of literally any file in a project. Just to to make 100% sure I’m working with the right repository.

In Visual Studio I’d hover on a tab, and confirm which repository clone I’m in:

In Xcode, in fastest way I’ve found is to open the file in Finder:

With the growing prevalence of AI-assisted coding there’s also a growing benefit to directly referencing source files. For example when guiding a LLM to read the source files you know are relevant to solving a task. Xcode generally just gets in the way here.

5. Back / Forward mouse buttons

Admittedly, this isn’t so much an Xcode issue as a MacOS thing. But it does impact my Xcode experience, and allows me to pad my list to 5 items.

Cut me some slack, it’s at the bottom of the list.

Ever since my first trusty Logitech Mx518, I’ve loved my two mouse side-buttons. Moving backwards and forwards through tabs and pages has been a delight.

To the complete surprise of no one who uses Apple products, Apple doesn’t really like 3rd party products. In this case, a 3rd party heretic mouse’s fourth and fifth buttons. At least, Apple doesn’t like them enough to allow them to be easily used in any of their first-party applications.

VsCode appears to detect and allow these buttons to behave just as expected on MacOS, as they do on Windows or Linux. But woe is you if you’d like to natively use the 4th and 5th mouse button in Safari or Xcode.

Alexei Baboulevitch has come up with a lovely little app called Sensible side buttons which emulates the gesture Apple would prefer you do to trigger ‘back’ and ‘forward’, but with the fourth and fifth mouse button. Yay! Safari and Xcode now responds just like VsCode. Conversely, turning this app on actually breaks the native support in VsCode. So at the time of writing, I can leave Sensible side buttons off and have my satanic buttons function in VsCode, or turn it on and have the buttons work in Safari and Xcode.

Sigh… Perhaps the follow-up work by Jan Hülsmann, Sane side buttons, resolves this issue. I’ve yet to try that one.

I just wish this didn’t have to be so difficult.

There’s some good too…

We can’t have a bunch of con’s without a few pro’s too and Xcode absolutely offers some nice functionality I found myself wanting in other IDEs.

1. Debugging specificity

In debug-mode Xcode underlines the specific part of a line it’s about to execute, i.e. the funcHello() next in line to run is clearly underlined:

Lovely. I wish Visual Studio and other IDEs would do this.

Visual Studio only has an arrow telling you something on this line is next.

2. Execution context stacking

Something I only recently discovered what that double-clicking a thread will display a kind of execution context stack:

This looks very helpful in terms of exploring new code-bases and figuring a code-path through several different functions all at once, without having to manually click through files.

I don’t think Visual Studio offers anything like this view.

Final thoughts

Given Xcode’s integrated debugging support, I (currently) still prefer it over VsCode on MacOs. If I find myself developing and debugging piles of C++ code on an Apple device again, it’d only be fair to give VsCode another shake there. My past outings with VsCode often only make me yearn for Visual Studio.

Given Xcode’s current rating of 3.1 stars on the AppStore – down from 3.7 when I first started on this article – I’m unlikely to be the only person who has some grumblings with Xcode.

Here’s hoping some of these issues get resolved in 2026!