5 ms·

I’m curious enough to give this a try, but can it really be good when Xcode is so bad? Are they written by different teams?

nielsbot 5y ago
What's so bad about Xcode? I use Xcode for my day job--honestly curious which parts people don't like.
- porcoda 5y ago
  It’s the Internet - if someone says “I use <X>”, then inevitably you’ll see a handful of passionate comments along the lines of “<X> is the worst technology created since the dawn of man, and <creator of X> really should admit failure and redo it from scratch to make ME, an Internet Commenter, happy”. I’ve learned to just tune them out and use my own judgement and preferences to decide if a tool is effective for me.
  - nielsbot 5y ago
    Thanks. I like Xcode even if others don't. And I have used many other IDEs (IntelliJ, VS Code, even NetBeans). I'm honestly curious what the sore points are.
- iainmerrick 5y ago
  I do use it in my day job, so I'm not saying it's the worst, but I have been pretty frustrated with it for some time now! Very happy to share :) This is from my experience working with a couple of large iOS team projects written in Swift, with CocoaPods dependencies. YMMV for other setups. I've hit a bunch of problems in the IDE itself, the Swift toolchain, the iOS Simulator, and in the integration between them. First, it's slow: compilation is slow, running tests is slow, starting the app is slow, debugging is slow (generally tens of seconds to attach when it hits a breakpoint), inspecting the view hierarchy is slow (and often just doesn't work). Code completion is slow and unreliable (and currently doesn't work at all for third-party frameworks in Xcode 13). Besides the slowness, things get out of sync a lot, I think because it's doing tasks in parallel in an attempt to do them faster. I frequently see out-of-date compile errors and warnings highlighted in the IDE, because it hasn't finished the appropriate bit of the build yet, or because you're currently working in another target. Production code and unit tests are in different targets because that's how Xcode wants it, but because they drift out of sync so much and the tooling is slow, test-driven development is really tedious and slow. It's usually easier just to build and run the whole app. The UI is usable, but tabs are very clunky and limited compared to other popular IDEs (e.g., you can't just drag to create a new split in any direction). The "assistant editor" for things like associated header files isn't necessarily a bad idea, but again it's clunky and limited. There are too many "mystery meat" icons with no labels attached -- I constantly get mixed up between Issues, Test and Debug. The monolithic project file format is really awful, especially if you're working in a team. It's not usefully human-readable or editable, and every so often Xcode will make random changes to random GUIDs; you just have to shrug and check it in and hope that nobody else gets a merge conflict. The same applies to Interface Builder and all the other embedded rich editors. Just opening an icon or color resource will likely make some random meaningless edit -- why? Adding a file to the project takes an age. "New File...", wait several seconds, "Choose a template for your new file", I don't care, type a filename, delete it again because that's actually the search field for templates, press Next, wait a few more seconds, and finally you're at the file dialog. Why do files even need to be added? It would be so much better if it just reflected the file system. As it stands, files can be reordered (does anyone take the trouble to arrange them in a sensible order? if so, how on earth do you maintain that in a team project?), accidentally omitted from the project, in a different group than its actual position on disk... why? Finally, some of this stuff might get better with more familiarity (e.g., if you set up keybindings) except that the UI tends to change substantially on each release! If you look for advice on StackOverflow on fixing some obscure problem with certificates (and I bet at least 90% of iOS developers have done this) you'll find five completely different solutions for five different versions of Xcode. Oh, and each new release is ~10GB and takes hours to install, literally hours of Archive Tool opening and verifying something called a .xip file. There's no perfect IDE, and I'm not even saying Xcode is uniquely bad, but for each of my complaints here there's another tool that does it better. VS Code is really fast (I'm increasingly using it as a companion editor for everything other than .swift files); Android Studio for all its flaws has nicer tab management, and its interface builder equivalent works really well.
nicoburns 5y ago
I think a lot of Xcode’s issues stem from it being a 20+ year old program with a lot of the legacy baggage that comes with that. I’ve actually found it not too bad with the recent updates. If they could get rid of the stupid project file format then I might actually like it.
interpol_p 5y ago
A lot of people say this but I find Xcode quite good. I can load a huge project and be editing in around 5 seconds, compared to waiting several minutes in Android Studio. It has very clear in-line diffing, incredibly fast project-wide search, and very consistent hotkeys making keyboard navigation very simple (especially if you like to spatially arrange your editors via hotkey). I also find that its UI is responsive and well designed, good aesthetic choices, consistent stroke widths on icons, consistent typography, etc Some of the "badness" of Xcode comes when you have to deal with a huge, mixed-language project (Objective-C, Objective-C++, C++, C, Swift). But then, I don't know of an IDE that handles that situation gracefully, and in a unified way. Xcode still manages to parse and autocomplete all the above languages with a good degree of grace, but the clunkiness comes in knowing how to connect them all together and why the damn thing won't build or link — it's pretty hard to shield the programmer from that complexity
- viktorcode 5y ago
  I have some major gripes with Xcode as it is now (though otherwise I find it to be quite good): 1. Startup time is too long. Often I find myself double clicking a code file in Finder to preview it only to be greeted with jumping Xcode icon. Riiiight, here we goooo, boss. Just 2-3 seconds, boss. It should open the file straight away, and then lazily load the rest of its frameworks if necessary. 2. Code editor is very bad with large files. Be it large JSON data, or C++ files from Unity's code generator, navigating and editing those is painful. Every typed symbol will incur a delay, every switch to different place in that file is noticeable too. This is by far the worst of all other code editors I used, but I get it, few people have to work with huge amount of text. 3. pbxproj format for project. Ever worked in a team where several people adding and removing files in their commits? Happy project merging then. Or rather, happy searching for a tool to auto-regenerate the project. This format has to go.
  - interpol_p 5y ago
    Agree on all three points 1. I certainly wouldn't use Xcode for editing single files from the Finder. For opening a huge project with thousands of files, ready to build and fully indexed for autocompletion and finding, it still only takes a few seconds. That's the metric that impresses me 2. Yeah I have one long file in my current project (hundreds of thousands of lines) and it isn't pleasant to edit in Xcode 3. I am quite good at merging pbxproj after 10 years of doing it, even when files are added and removed. But yeah, it is a bit hairy
armadsen 5y ago
They are written by different teams (source: I know people who have worked on each team). They share things, of course. In fact, the "new" (as of a few years ago) source editor in Xcode came out of Swift Playgrounds for iOS originally.
iainmerrick 5y ago
Some interesting replies in this thread! I want to expand on my flippant "Xcode is so bad" a bit. A lot of the stuff I dislike about Xcode impacts large, complex, multi-team, multi-language projects, with nib files and storyboards and other resources. I guess a lot of that is simply irrelevant to Swift Playgrounds, so it could be better just by dropping those features! On the other hand, another big complaint I (and others) have is that the Swift compiler is too slow. That does affect Playgrounds; I've tried using playgrounds within Xcode and been very underwhelmed, so I'm skeptical that the standalone app would be any better. But people here are reporting how much their kids enjoy using Playgrounds. I do like Swift on the whole, but I wouldn't have thought it to be pleasant as a first language for beginners. So I'm curious! I wonder how big a difference good hardware makes -- recent iPad hardware is very good indeed, so I can see how a more focused app on an iPad might outperform Xcode on an x86 Macbook "Pro".

nielsbot 5y ago

What's so bad about Xcode? I use Xcode for my day job--honestly curious which parts people don't like.

porcoda 5y ago
It’s the Internet - if someone says “I use <X>”, then inevitably you’ll see a handful of passionate comments along the lines of “<X> is the worst technology created since the dawn of man, and <creator of X> really should admit failure and redo it from scratch to make ME, an Internet Commenter, happy”. I’ve learned to just tune them out and use my own judgement and preferences to decide if a tool is effective for me.
- nielsbot 5y ago
  Thanks. I like Xcode even if others don't. And I have used many other IDEs (IntelliJ, VS Code, even NetBeans). I'm honestly curious what the sore points are.
iainmerrick 5y ago
I do use it in my day job, so I'm not saying it's the worst, but I have been pretty frustrated with it for some time now! Very happy to share :) This is from my experience working with a couple of large iOS team projects written in Swift, with CocoaPods dependencies. YMMV for other setups. I've hit a bunch of problems in the IDE itself, the Swift toolchain, the iOS Simulator, and in the integration between them. First, it's slow: compilation is slow, running tests is slow, starting the app is slow, debugging is slow (generally tens of seconds to attach when it hits a breakpoint), inspecting the view hierarchy is slow (and often just doesn't work). Code completion is slow and unreliable (and currently doesn't work at all for third-party frameworks in Xcode 13). Besides the slowness, things get out of sync a lot, I think because it's doing tasks in parallel in an attempt to do them faster. I frequently see out-of-date compile errors and warnings highlighted in the IDE, because it hasn't finished the appropriate bit of the build yet, or because you're currently working in another target. Production code and unit tests are in different targets because that's how Xcode wants it, but because they drift out of sync so much and the tooling is slow, test-driven development is really tedious and slow. It's usually easier just to build and run the whole app. The UI is usable, but tabs are very clunky and limited compared to other popular IDEs (e.g., you can't just drag to create a new split in any direction). The "assistant editor" for things like associated header files isn't necessarily a bad idea, but again it's clunky and limited. There are too many "mystery meat" icons with no labels attached -- I constantly get mixed up between Issues, Test and Debug. The monolithic project file format is really awful, especially if you're working in a team. It's not usefully human-readable or editable, and every so often Xcode will make random changes to random GUIDs; you just have to shrug and check it in and hope that nobody else gets a merge conflict. The same applies to Interface Builder and all the other embedded rich editors. Just opening an icon or color resource will likely make some random meaningless edit -- why? Adding a file to the project takes an age. "New File...", wait several seconds, "Choose a template for your new file", I don't care, type a filename, delete it again because that's actually the search field for templates, press Next, wait a few more seconds, and finally you're at the file dialog. Why do files even need to be added? It would be so much better if it just reflected the file system. As it stands, files can be reordered (does anyone take the trouble to arrange them in a sensible order? if so, how on earth do you maintain that in a team project?), accidentally omitted from the project, in a different group than its actual position on disk... why? Finally, some of this stuff might get better with more familiarity (e.g., if you set up keybindings) except that the UI tends to change substantially on each release! If you look for advice on StackOverflow on fixing some obscure problem with certificates (and I bet at least 90% of iOS developers have done this) you'll find five completely different solutions for five different versions of Xcode. Oh, and each new release is ~10GB and takes hours to install, literally hours of Archive Tool opening and verifying something called a .xip file. There's no perfect IDE, and I'm not even saying Xcode is uniquely bad, but for each of my complaints here there's another tool that does it better. VS Code is really fast (I'm increasingly using it as a companion editor for everything other than .swift files); Android Studio for all its flaws has nicer tab management, and its interface builder equivalent works really well.

nicoburns 5y ago

I think a lot of Xcode’s issues stem from it being a 20+ year old program with a lot of the legacy baggage that comes with that. I’ve actually found it not too bad with the recent updates. If they could get rid of the stupid project file format then I might actually like it.

interpol_p 5y ago

A lot of people say this but I find Xcode quite good. I can load a huge project and be editing in around 5 seconds, compared to waiting several minutes in Android Studio. It has very clear in-line diffing, incredibly fast project-wide search, and very consistent hotkeys making keyboard navigation very simple (especially if you like to spatially arrange your editors via hotkey). I also find that its UI is responsive and well designed, good aesthetic choices, consistent stroke widths on icons, consistent typography, etc Some of the "badness" of Xcode comes when you have to deal with a huge, mixed-language project (Objective-C, Objective-C++, C++, C, Swift). But then, I don't know of an IDE that handles that situation gracefully, and in a unified way. Xcode still manages to parse and autocomplete all the above languages with a good degree of grace, but the clunkiness comes in knowing how to connect them all together and why the damn thing won't build or link — it's pretty hard to shield the programmer from that complexity

viktorcode 5y ago
I have some major gripes with Xcode as it is now (though otherwise I find it to be quite good): 1. Startup time is too long. Often I find myself double clicking a code file in Finder to preview it only to be greeted with jumping Xcode icon. Riiiight, here we goooo, boss. Just 2-3 seconds, boss. It should open the file straight away, and then lazily load the rest of its frameworks if necessary. 2. Code editor is very bad with large files. Be it large JSON data, or C++ files from Unity's code generator, navigating and editing those is painful. Every typed symbol will incur a delay, every switch to different place in that file is noticeable too. This is by far the worst of all other code editors I used, but I get it, few people have to work with huge amount of text. 3. pbxproj format for project. Ever worked in a team where several people adding and removing files in their commits? Happy project merging then. Or rather, happy searching for a tool to auto-regenerate the project. This format has to go.
- interpol_p 5y ago
  Agree on all three points 1. I certainly wouldn't use Xcode for editing single files from the Finder. For opening a huge project with thousands of files, ready to build and fully indexed for autocompletion and finding, it still only takes a few seconds. That's the metric that impresses me 2. Yeah I have one long file in my current project (hundreds of thousands of lines) and it isn't pleasant to edit in Xcode 3. I am quite good at merging pbxproj after 10 years of doing it, even when files are added and removed. But yeah, it is a bit hairy

armadsen 5y ago

They are written by different teams (source: I know people who have worked on each team). They share things, of course. In fact, the "new" (as of a few years ago) source editor in Xcode came out of Swift Playgrounds for iOS originally.

iainmerrick 5y ago

Some interesting replies in this thread! I want to expand on my flippant "Xcode is so bad" a bit. A lot of the stuff I dislike about Xcode impacts large, complex, multi-team, multi-language projects, with nib files and storyboards and other resources. I guess a lot of that is simply irrelevant to Swift Playgrounds, so it could be better just by dropping those features! On the other hand, another big complaint I (and others) have is that the Swift compiler is too slow. That does affect Playgrounds; I've tried using playgrounds within Xcode and been very underwhelmed, so I'm skeptical that the standalone app would be any better. But people here are reporting how much their kids enjoy using Playgrounds. I do like Swift on the whole, but I wouldn't have thought it to be pleasant as a first language for beginners. So I'm curious! I wonder how big a difference good hardware makes -- recent iPad hardware is very good indeed, so I can see how a more focused app on an iPad might outperform Xcode on an x86 Macbook "Pro".