7 ms·

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

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 8mo 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 8mo 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.
  - jahnu 8mo ago
    > The Debugger is even flakier than usual when Lambdas are involved. You can’t step into a lambda stored in a std::function Absolute nightmare if you don’t know which lambda it might be so you can set a breakpoint in it. Honestly, compared to Visual Studio, Xcode is 20 years behind.
    - socalgal2 8mo ago
      You're holding it wrong. You're not supposed to code for Apple products using C++. You're supposed to use Swift (only half joking)
  - IcyWindows 8mo ago
    What Copilot can use the IDE when actively debugging.
  - asimovDev 8mo ago
    Have you tried Clion for C++? I am not an experienced C dev by any means, but I am satisfied with their debugging for all the projects I worked on in that IDE. It has a free community license so no need to pay
    - neutronicus 8mo ago
      I have not! Ultimately, my complaints only really apply to coding for work. For personal projects I find emacs / LSP / dap more than sufficient. But to be honest this is still something I should maybe bring up with our tools team. If it works well with .xcodeproj files it might be a good fit for our team.
  - pasc1878 8mo ago
    Xcode is really only usable for Objective-C, C and Swift its support for C++ e.g. simple things like formatting and definitions and debugging for C++ are as you note are just poor Visual Studio does treat C++ as a first class language (I suspect because that was the first non C language it supported and Windows apps used C++ in the 1990s) I would try Clion for C++ if you can't use VS. Eclipse was reasonable 15 years ago when Apple used gcc.
- plorkyeran 8mo ago
  Historically one of the big problems with Xcode has been that they only dogfood. There’s people on the team that have not touched any other IDE in decades. They’ve gotten used to all of the quirks, and just don’t really know that things could be better. Every new improvement has to be designed from scratch rather than just ripping off what other IDEs do better. Apple internally has structured their projects to not run into all of the debugger performance cliffs, but don’t provide any guidance on how to do the same thing and don’t proactively fix the problems they’ve avoided. Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree.
  - int_19h 8mo ago
    > There’s people on the team that have not touched any other ... in decades. From using Apple products, I get the impression that the same is true for many other things.
  - jamesfinlayson 8mo ago
    > Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree. Wow. I won't say Xcode is anywhere near the worst IDE I've ever used (Eclipse) but I wouldn't say it's anywhere near best in class either.
- saagarjha 8mo ago
  > 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 is so you can see function names for system frameworks. You can step into them if you want too even if Xcode tries to stop you doing it by default.
Eric_WVGG 8mo ago
Like you, I think that Xcode maybe gets a worse rap than it deserves, but it's also endlessly frustrating. First, the performance is just bad. The responsiveness compared to apps like VSC or Panic’s Nova is night-and-day. The attention given to the design of new features is piss-poor. Placing the AI functionality on the left sidebar makes no sense; all the other tools on the left are project management; the "let me run weird functions and interact with stuff" UIs like terminal, debug and logs are in the bottom panel. Or maybe a new tab in the main workspace area? The SwiftUI preview canvas can't be floated as a separate window, making it all but useless on anything smaller than a 16" MBP (and only barely usable there). In fact, I think it might be impossible to use Xcode in multiple screens altogether…? Old simulator versions and cache files hang around forever, you need a third-party app like DevCleaner just to keep your storage from filling with nonsense. Cryptic messages like "copying symbols to device"… clear-cache that doesn't seem to clear-cache, that stupid list UI for info.plist… I never thought I'd have anything nice to say about PNPM package management, but you can always just delete `node_modules` and reinstall and count on things working. Swift package management is a cryptic mess, and their insistence on using a GUI instead of a basic JSON manifest just compounds it. Like the info.plist thing, a lot of Xcode is based on a developer UI philosophy from the Mac Classic days that has mostly been abandoned by the rest of the world. Mostly, I think the vitriol surrounding Xcode is that Apple seems to think they're doing a good job; meanwhile their most ardent and adept users are insisting that they are not. Same boat as MacOS, really.
- saagarjha 8mo ago
  Nit: symbol files are copied from a device.
  - Eric_WVGG 8mo ago
    Thanks for the correction. Still have no idea what it actually means, or why it takes so crazy long. If they have to update symbols upon every OS version bump, are they cleaning out the old ones? It's so frustratingly opaque.
    - 8mo ago
trinix912 8mo ago
Mostly the fact that for the past 10 years they've been adding new features but never finished them and taken the time to properly bugfix them along the way. Just a few I ran into recently: - Interface Builder is stuck in early 2010s. Not only is the property panel missing half of options we now take for granted everywhere else (like corner radius), it also randomly won't read fonts in the current project, will crash the entire IDE if you Cmd-Z a big change (things like unembedding a view) and half the UI is still not rendered the way it will be on the phone. Yes, Swift UI exists, but most bigger apps are still XIBs and Storyboards and it's going to remain that way for quite some time. - Autocomplete is a hit or miss. Very much like the mid-90s Microsoft IDEs where you'd get totally useless results until you've typed the whole line out already. It can be done well, look at AppCode. - Syntax highlighting feels pretty much the same. Randomly flashes on and off, often doesn't highlight until return is pressed, takes a long time to load on large files etc. - Git integration is by far the worst I've seen out of any IDE and I've seen many. I'd go as far as to say that SourceSafe integration in VB6 was done better. Just the whole layout, modal-on-modal returning to the first modal on an error in the second and so on. It's crashed when rebasing a few times too, I don't trust it with larger operations since. - Documentation browser is this annoying little window with semi-useful search. But don't worry, the docs in there are useless anyways. I could go on and on about their approach to docs but maybe next time. Don't even get me started on performance. Things like switching file tabs should be instant by now but there are still noticeable delays for larger files and IB screens. Plus there's now two kinds of tabs (app-level and file-level) to add to the mess.
ASalazarMX 8mo ago
> 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 8mo ago
  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.
  - 8mo ago
semiinfinitely 8mo ago
its almost tautological that a person who has been using xcode for 10 years would be incapable of seeing any flaws in it
bromuro 8mo ago
I also enjoy working with XCode. It has glitches and it is a bit slow, but I love the look and feel and it I am positively inspired working with it.
indycliff 8mo ago
There is barely anything wrong with Xcode. I'd rather it than the bloat that is Android Studio or Visual Code. Haters gonna hate. I also write apps for every Apple platform and really no complaints except I wouldn't mind a better Vim mode (it does however suffice!)
sgt 8mo ago
I haven't been using Xcode continuously for that long. But I recall being a pleasure every time I use it. Except when it crashed occasionally, but that was luckily rare. It sounds like OP doesn't like the way Xcode does things differently to other IDE's.
snarf21 8mo ago
If nothing else, an update to the pbxproj file format would be life changing. Most of my time fighting git is dealing with project file merges.
- seankit 8mo ago
  as of Xcode 16, the default uses actual directories for folders instead of file references in the pbxproj file, which eliminates those annoying merge conflicts. at my work it took a bit of effort to move the project over to using folders but it was 100% worth it.
- ninkendo 8mo ago
  It’s so great when the files on the navigator pane aren’t sorted, and then if you right-click sort, it rewrites half your pbxproj file and you get merge conflicts everywhere. So then nobody sorts the files because they don’t want to deal with it. Why can’t the sorting be a view thing that’s independent of the contents of the project file? Who knows. When I used it in a team, I had to write a build step that would fail the build if the pbxproj file wasn’t sorted. (Plus a custom target that would sort it for you.) It was the only way to make sure it never got unsorted in the first place.
- RobMurray 8mo ago
  You can work around this by putting most of your project in spm packages and making the Xcode project a small shim that depends on the other packages. Tuist makes this even better, it generates the Xcode project so you don't commit the pbxproj files.
st3fan 8mo ago
It has become a meme to complain about Xcode. When I ask devs what they don't like about it it is usually very subjective or a misunderstanding. Take it all with a grain of salt. It is one of the most advanced and amazing IDEs out there IMO.
perplex 8mo ago
Xcode is abysmal on a large codebase. Freezes constantly on operations. The most useful features stall the entire program, things like: test navigator, quick open files, debugger, etc.. But I agree that Xcode runs fine on small projects and recent version feel stable compare to past releases.
jbm 8mo ago
I sometimes have to build code for the apple watch. Getting it to pair with XCode is incredibly frustrating and is the opposite of what you would expect.
Aloisius 8mo ago
While I don't quite have the same problems as others have, there are some pain points. Stepping through the debugger too fast will sometimes put the debugger in a weird state where step never breaks again and all other breakpoints stop working. Git pull through the UI with stash and merge can blow away your local changes if there is a conflict. The changes aren't stashed. They're just gone. Xcode likes to sometimes recompile files that haven't changed slowing everything down, sometimes significantly depending on the file. No idea why. It can get very confused if you're missing a parenthesis in the wrong place in a SwiftUI View leading to opaque swift compiler errors about code being too complex. Even mildly complex use of a swift #Predicate will cause an error about it being too complex forcing you to break them down into smaller pieces and even then it takes far too long to build even on a brand new machine. The simulators are quite slow to start/update/run and xcode sometimes fails to shut them down completely when quitting leading to them just continually running eating memory unless you kill the processes manually. The simulators also are really limited in their functionality. No background processes, spotlight, network degradation simulation, out of memory killer, etc. The profiler sometimes just fails to start an app correctly, immediately ending a run forcing you to close the profiler and reopen it again before it'll start working. Symbol refactor (rename) can be painfully slow where the UI just locks up until it can find all the references. Xcode likes to duplicate package dependencies in xcodeproj. It just creates new hashes for the same library and adds it as a dependency over and over again, so when the link phase happens, it adds libraries repeatedly over and over and over again unless you manually clear them out. Not sure what causes this, perhaps updating the version or merges between users.
- mindok 8mo ago
  I may be wrong, but the simulators seem to be Intel binaries which mess with audio since the last macOS update I did, so no zoom calls with XCode open for me.
ibero 8mo ago
putting a build on your own apple watch is horrific. it constantly disconnects, requires restarts and other nonsense techniques. i legit do not know how you can not be running into these problems if you are developing on those platforms.
tom_ 8mo ago
Inflexible window layout. (For example, suppose you want to see breakpoints list, call stack, and find results simultaneously. You can't, as they all share the same panel. Which is always on the left of the window.)
- tumultco 8mo ago
  Hit command-t for file > new > new window tab. Then if you want you can drag out the tab into a new window. Now you can view these both at once. Window tabs are weird but powerful. You can even name them and then have the preferences > behaviors show or hide these named ones at certain times.
niek_pas 8mo ago
I have never used any other IDE where quitting and relaunching it would fix build errors. And, this isn’t strictly XCode, but my least favorite thing about writing apps for apples platforms is all the admin overhead. You need an Apple development account, signing certificates, app groups, entitlements… just let me compile my code man.
mabedan 8mo ago
it's truly a bismal experience compared to what else is out there (my experience is with rust, python and ts inside vsc). Often autocomplete is hopeless and doesn't help you with the most simple things like picking from multiple initializers, or changing to a different signature of a function call. the project setup is this mystery Xcode project file, instead of a standardized yml or something that anyone can modify and understand. I have to say provisioning has improved a lot. I remember back in 2008, it was really a pain to get anything working. This is not necessarily about Xcode, but maybe it should be: screen shots for your app. they need screenshots for 454 device types, and zero automation in their own tooling. the layout is also very inflexible. they dictate a couple of panels and that's how you _must_ use them. that's unlike any other modern IDE.
zarzavat 8mo ago
Xcode is perpetually decade(s) behind the curve. VSCode is so much more advanced, even Atom 10 years ago was. To put it in a language Apple understands, it's like forcing music producers to use GarageBand when everyone else is on Logic.
urbandw311er 8mo ago
As others have said, I suspect you've just grown accustomed to its quirks and defects and learned to work around them. For example... * always refresh X before doing Y. * if you see this signing error, clear this cache. * don't try to drag this file here because it gets linked in the wrong way ...and so on. If you were able to use a magical, fast, bug-fixed, version where everything 'just worked' at pace, I imagine you would begin to realise just how much you have been putting up with!
MoonWalk 8mo ago
I've been using Xcode since it was Project Builder. It has improved in many ways. And since the advent of the App Store, the insufferable/inexcusable nightmare of "signing" has vastly improved. Most of the problems I encounter now resulted from the fiasco that is SwiftUI. I used to really enjoy development, and built a few mobile apps singlehandedly... even at a well-known company or two. But now I'm struggling to get one chunk of functionality at a time done on a from-scratch app, because SwiftUI and the underlying "reactive" paradigm were so poorly conceived and defectively implemented. Development is now miserable drudgery, and I never feel confident about the result. The absurd gymnastics to trick the UI into doing what you want; and the hypocritical, conflicting edicts for Swift and SwiftUI... it all barely hangs together. The fact that Apple rolled out a new UI toolkit that didn't support the most fundamental paradigm in mobile applications, a stack of progressive views for the user to proceed through, tells you how far off the rails they went since introducing the original and solid SDK. And testing is going to be a nightmare... or simply futile.

flohofwoe 8mo 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 8mo 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.
- jahnu 8mo ago
  > The Debugger is even flakier than usual when Lambdas are involved. You can’t step into a lambda stored in a std::function Absolute nightmare if you don’t know which lambda it might be so you can set a breakpoint in it. Honestly, compared to Visual Studio, Xcode is 20 years behind.
  - socalgal2 8mo ago
    You're holding it wrong. You're not supposed to code for Apple products using C++. You're supposed to use Swift (only half joking)
- IcyWindows 8mo ago
  What Copilot can use the IDE when actively debugging.
- asimovDev 8mo ago
  Have you tried Clion for C++? I am not an experienced C dev by any means, but I am satisfied with their debugging for all the projects I worked on in that IDE. It has a free community license so no need to pay
  - neutronicus 8mo ago
    I have not! Ultimately, my complaints only really apply to coding for work. For personal projects I find emacs / LSP / dap more than sufficient. But to be honest this is still something I should maybe bring up with our tools team. If it works well with .xcodeproj files it might be a good fit for our team.
- pasc1878 8mo ago
  Xcode is really only usable for Objective-C, C and Swift its support for C++ e.g. simple things like formatting and definitions and debugging for C++ are as you note are just poor Visual Studio does treat C++ as a first class language (I suspect because that was the first non C language it supported and Windows apps used C++ in the 1990s) I would try Clion for C++ if you can't use VS. Eclipse was reasonable 15 years ago when Apple used gcc.
plorkyeran 8mo ago
Historically one of the big problems with Xcode has been that they only dogfood. There’s people on the team that have not touched any other IDE in decades. They’ve gotten used to all of the quirks, and just don’t really know that things could be better. Every new improvement has to be designed from scratch rather than just ripping off what other IDEs do better. Apple internally has structured their projects to not run into all of the debugger performance cliffs, but don’t provide any guidance on how to do the same thing and don’t proactively fix the problems they’ve avoided. Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree.
- int_19h 8mo ago
  > There’s people on the team that have not touched any other ... in decades. From using Apple products, I get the impression that the same is true for many other things.
- jamesfinlayson 8mo ago
  > Every time I’ve talked to someone who has worked on Xcode they’ve expressed the opinion that Xcode is best-in-class and they simply don’t understand why people disagree. Wow. I won't say Xcode is anywhere near the worst IDE I've ever used (Eclipse) but I wouldn't say it's anywhere near best in class either.
saagarjha 8mo ago
> 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 is so you can see function names for system frameworks. You can step into them if you want too even if Xcode tries to stop you doing it by default.

Eric_WVGG 8mo ago

Like you, I think that Xcode maybe gets a worse rap than it deserves, but it's also endlessly frustrating. First, the performance is just bad. The responsiveness compared to apps like VSC or Panic’s Nova is night-and-day. The attention given to the design of new features is piss-poor. Placing the AI functionality on the left sidebar makes no sense; all the other tools on the left are project management; the "let me run weird functions and interact with stuff" UIs like terminal, debug and logs are in the bottom panel. Or maybe a new tab in the main workspace area? The SwiftUI preview canvas can't be floated as a separate window, making it all but useless on anything smaller than a 16" MBP (and only barely usable there). In fact, I think it might be impossible to use Xcode in multiple screens altogether…? Old simulator versions and cache files hang around forever, you need a third-party app like DevCleaner just to keep your storage from filling with nonsense. Cryptic messages like "copying symbols to device"… clear-cache that doesn't seem to clear-cache, that stupid list UI for info.plist… I never thought I'd have anything nice to say about PNPM package management, but you can always just delete `node_modules` and reinstall and count on things working. Swift package management is a cryptic mess, and their insistence on using a GUI instead of a basic JSON manifest just compounds it. Like the info.plist thing, a lot of Xcode is based on a developer UI philosophy from the Mac Classic days that has mostly been abandoned by the rest of the world. Mostly, I think the vitriol surrounding Xcode is that Apple seems to think they're doing a good job; meanwhile their most ardent and adept users are insisting that they are not. Same boat as MacOS, really.

saagarjha 8mo ago
Nit: symbol files are copied from a device.
- Eric_WVGG 8mo ago
  Thanks for the correction. Still have no idea what it actually means, or why it takes so crazy long. If they have to update symbols upon every OS version bump, are they cleaning out the old ones? It's so frustratingly opaque.
  - 8mo ago

trinix912 8mo ago

Mostly the fact that for the past 10 years they've been adding new features but never finished them and taken the time to properly bugfix them along the way. Just a few I ran into recently: - Interface Builder is stuck in early 2010s. Not only is the property panel missing half of options we now take for granted everywhere else (like corner radius), it also randomly won't read fonts in the current project, will crash the entire IDE if you Cmd-Z a big change (things like unembedding a view) and half the UI is still not rendered the way it will be on the phone. Yes, Swift UI exists, but most bigger apps are still XIBs and Storyboards and it's going to remain that way for quite some time. - Autocomplete is a hit or miss. Very much like the mid-90s Microsoft IDEs where you'd get totally useless results until you've typed the whole line out already. It can be done well, look at AppCode. - Syntax highlighting feels pretty much the same. Randomly flashes on and off, often doesn't highlight until return is pressed, takes a long time to load on large files etc. - Git integration is by far the worst I've seen out of any IDE and I've seen many. I'd go as far as to say that SourceSafe integration in VB6 was done better. Just the whole layout, modal-on-modal returning to the first modal on an error in the second and so on. It's crashed when rebasing a few times too, I don't trust it with larger operations since. - Documentation browser is this annoying little window with semi-useful search. But don't worry, the docs in there are useless anyways. I could go on and on about their approach to docs but maybe next time. Don't even get me started on performance. Things like switching file tabs should be instant by now but there are still noticeable delays for larger files and IB screens. Plus there's now two kinds of tabs (app-level and file-level) to add to the mess.

ASalazarMX 8mo ago

> 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 8mo ago
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.
- 8mo ago

semiinfinitely 8mo ago

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

bromuro 8mo ago

I also enjoy working with XCode. It has glitches and it is a bit slow, but I love the look and feel and it I am positively inspired working with it.

indycliff 8mo ago

There is barely anything wrong with Xcode. I'd rather it than the bloat that is Android Studio or Visual Code. Haters gonna hate. I also write apps for every Apple platform and really no complaints except I wouldn't mind a better Vim mode (it does however suffice!)

sgt 8mo ago

I haven't been using Xcode continuously for that long. But I recall being a pleasure every time I use it. Except when it crashed occasionally, but that was luckily rare. It sounds like OP doesn't like the way Xcode does things differently to other IDE's.

snarf21 8mo ago

If nothing else, an update to the pbxproj file format would be life changing. Most of my time fighting git is dealing with project file merges.

seankit 8mo ago
as of Xcode 16, the default uses actual directories for folders instead of file references in the pbxproj file, which eliminates those annoying merge conflicts. at my work it took a bit of effort to move the project over to using folders but it was 100% worth it.
ninkendo 8mo ago
It’s so great when the files on the navigator pane aren’t sorted, and then if you right-click sort, it rewrites half your pbxproj file and you get merge conflicts everywhere. So then nobody sorts the files because they don’t want to deal with it. Why can’t the sorting be a view thing that’s independent of the contents of the project file? Who knows. When I used it in a team, I had to write a build step that would fail the build if the pbxproj file wasn’t sorted. (Plus a custom target that would sort it for you.) It was the only way to make sure it never got unsorted in the first place.
RobMurray 8mo ago
You can work around this by putting most of your project in spm packages and making the Xcode project a small shim that depends on the other packages. Tuist makes this even better, it generates the Xcode project so you don't commit the pbxproj files.

st3fan 8mo ago

It has become a meme to complain about Xcode. When I ask devs what they don't like about it it is usually very subjective or a misunderstanding. Take it all with a grain of salt. It is one of the most advanced and amazing IDEs out there IMO.

perplex 8mo ago

Xcode is abysmal on a large codebase. Freezes constantly on operations. The most useful features stall the entire program, things like: test navigator, quick open files, debugger, etc.. But I agree that Xcode runs fine on small projects and recent version feel stable compare to past releases.

jbm 8mo ago

I sometimes have to build code for the apple watch. Getting it to pair with XCode is incredibly frustrating and is the opposite of what you would expect.

Aloisius 8mo ago

While I don't quite have the same problems as others have, there are some pain points. Stepping through the debugger too fast will sometimes put the debugger in a weird state where step never breaks again and all other breakpoints stop working. Git pull through the UI with stash and merge can blow away your local changes if there is a conflict. The changes aren't stashed. They're just gone. Xcode likes to sometimes recompile files that haven't changed slowing everything down, sometimes significantly depending on the file. No idea why. It can get very confused if you're missing a parenthesis in the wrong place in a SwiftUI View leading to opaque swift compiler errors about code being too complex. Even mildly complex use of a swift #Predicate will cause an error about it being too complex forcing you to break them down into smaller pieces and even then it takes far too long to build even on a brand new machine. The simulators are quite slow to start/update/run and xcode sometimes fails to shut them down completely when quitting leading to them just continually running eating memory unless you kill the processes manually. The simulators also are really limited in their functionality. No background processes, spotlight, network degradation simulation, out of memory killer, etc. The profiler sometimes just fails to start an app correctly, immediately ending a run forcing you to close the profiler and reopen it again before it'll start working. Symbol refactor (rename) can be painfully slow where the UI just locks up until it can find all the references. Xcode likes to duplicate package dependencies in xcodeproj. It just creates new hashes for the same library and adds it as a dependency over and over again, so when the link phase happens, it adds libraries repeatedly over and over and over again unless you manually clear them out. Not sure what causes this, perhaps updating the version or merges between users.

mindok 8mo ago
I may be wrong, but the simulators seem to be Intel binaries which mess with audio since the last macOS update I did, so no zoom calls with XCode open for me.

ibero 8mo ago

putting a build on your own apple watch is horrific. it constantly disconnects, requires restarts and other nonsense techniques. i legit do not know how you can not be running into these problems if you are developing on those platforms.

tom_ 8mo ago

Inflexible window layout. (For example, suppose you want to see breakpoints list, call stack, and find results simultaneously. You can't, as they all share the same panel. Which is always on the left of the window.)

tumultco 8mo ago
Hit command-t for file > new > new window tab. Then if you want you can drag out the tab into a new window. Now you can view these both at once. Window tabs are weird but powerful. You can even name them and then have the preferences > behaviors show or hide these named ones at certain times.

niek_pas 8mo ago

I have never used any other IDE where quitting and relaunching it would fix build errors. And, this isn’t strictly XCode, but my least favorite thing about writing apps for apples platforms is all the admin overhead. You need an Apple development account, signing certificates, app groups, entitlements… just let me compile my code man.

mabedan 8mo ago

it's truly a bismal experience compared to what else is out there (my experience is with rust, python and ts inside vsc). Often autocomplete is hopeless and doesn't help you with the most simple things like picking from multiple initializers, or changing to a different signature of a function call. the project setup is this mystery Xcode project file, instead of a standardized yml or something that anyone can modify and understand. I have to say provisioning has improved a lot. I remember back in 2008, it was really a pain to get anything working. This is not necessarily about Xcode, but maybe it should be: screen shots for your app. they need screenshots for 454 device types, and zero automation in their own tooling. the layout is also very inflexible. they dictate a couple of panels and that's how you _must_ use them. that's unlike any other modern IDE.

zarzavat 8mo ago

Xcode is perpetually decade(s) behind the curve. VSCode is so much more advanced, even Atom 10 years ago was. To put it in a language Apple understands, it's like forcing music producers to use GarageBand when everyone else is on Logic.

urbandw311er 8mo ago

As others have said, I suspect you've just grown accustomed to its quirks and defects and learned to work around them. For example... * always refresh X before doing Y. * if you see this signing error, clear this cache. * don't try to drag this file here because it gets linked in the wrong way ...and so on. If you were able to use a magical, fast, bug-fixed, version where everything 'just worked' at pace, I imagine you would begin to realise just how much you have been putting up with!

MoonWalk 8mo ago

I've been using Xcode since it was Project Builder. It has improved in many ways. And since the advent of the App Store, the insufferable/inexcusable nightmare of "signing" has vastly improved. Most of the problems I encounter now resulted from the fiasco that is SwiftUI. I used to really enjoy development, and built a few mobile apps singlehandedly... even at a well-known company or two. But now I'm struggling to get one chunk of functionality at a time done on a from-scratch app, because SwiftUI and the underlying "reactive" paradigm were so poorly conceived and defectively implemented. Development is now miserable drudgery, and I never feel confident about the result. The absurd gymnastics to trick the UI into doing what you want; and the hypocritical, conflicting edicts for Swift and SwiftUI... it all barely hangs together. The fact that Apple rolled out a new UI toolkit that didn't support the most fundamental paradigm in mobile applications, a stack of progressive views for the user to proceed through, tells you how far off the rails they went since introducing the original and solid SDK. And testing is going to be a nightmare... or simply futile.