My Xcode rant

It seems everyone who develops for OS X or iOS these days has their own rant about the problems with Apple’s development environment, Xcode. Well, here’s mine, excerpted from a message I sent to the xcode-users mailing list.

Xcode 3 was getting pretty good for awhile, but then Xcode 4 was released, a massive backwards step in functionality which has only been getting worse with its point releases. I have suffered, shockingly, very few of the crashes and data loss bugs which other people have been plagued with, but I have plenty of gripes just the same.

Xcode 4’s integrated layout may look good on paper, and even work better for some people, but for others it’s a hopeless struggle to manage screen space and get a consistent workflow going. Xcode 3’s ability to pop open and then close the build progress window was delightful; with Xcode 4 I just get the build log in my editor pane without being able to see the code I’m working on. Ditto that the IB integration into Xcode; with a windowed layout that would have been tolerable, but as it is I spend considerable time just going back and forth between interface and code views to see what the heck I’m doing – and no, tearing off Xcode 4’s tabs doesn’t make it better, because that has a near-100% tendency to completely destroy my window position and layout settings. Xcode 4 took away the class hierarchy view. It took away the ability to compile one file at a time. The integrated debugger console is painful and takes away from code editor screen space. Workspaces are just plain broken and do not work as advertised. The configuration editor is a step up, but unfortunately the “scheme” concept is a two steps down. Switching between Debug and Release should not require chugging through three settings panels to find the right switch. And don’t talk to me about the inability to shut off Git integration on a per-project basis (or, for that matter, at all). Why can’t I enable Guard Malloc or change the debugger used for unit tests? Why am I sacrificing valuable screen space (and I say that having a 27″ screen, fully aware that people are doing dev with Xcode 4 on 11″ Macbook Airs) for an iTunes-like status display when Xcode 3’s status bar was just as useful?

And Xcode 4 itself is, as a whole, sluggish in every respect. Operations of all kinds, from editing text to creating connections in IB to switching between code files, which were perceptually instantaneous in Xcode 3 take visible time in 4. Even those 200 milliseconds here and there add up to an overall feeling that I’m spending more time waiting for my development environment to catch up with my thinking than I am actually writing code. Yes, it’s very nice that the debugger console and utility panels slide neatly in and out with smooth animation, but I’m a developer; Apple doesn’t have to market eyecandy to me. I’d strongly prefer instant response. And all I get for all this trouble is ridiculously bloated memory usage forcing a restart of the program every several hours of serious work.

Before anyone asks, yes, I’ve filed several Radars. All have been closed as duplicates (which means I’ll never hear anything about them again) or ignored (same result). The impression I get from Apple is that they think that they have enough people who build their livelihoods on the iOS ecosystem that they don’t have to put any effort into improving the tools for those who give a darn about a time when writing code wasn’t an exercise in stockpiling $20,000 for a tripped out Mac Pro whose stats can compensate for Xcode’s flaws.

Some other good examples of the problems people have with Xcode:

6 thoughts on “My Xcode rant

  1. Dad

    Some of the things you are ranting against are in Xcode 4.

    a) some of the show/hide panes/views stuff is access via Edit Behaviors… in the Xcode menu, though it sounds a little bit like you may have figured that out (you talk about the debug area animating in)…

    b) The class hierarchy is there; go to the Symbol navigator and then de-select the appropriate icons down at the bottom of the column (turn off “show only project defined symbols” – the document icon).

    c) I think you can get the alternate debugger for unit tests by making a separate Scheme for your unit testing (seems that way to me, though I haven’t done this).

    e) Pretty sure you can just delete the repo from the organizer window Repositories tab source list and it’ll then be ignored.

    e) You can enable Guard Malloc in the Run area for the Scheme (so you can have a unit test Scheme with your favorite debugger and Guard Malloc turned on, say).

    f) Right click to hide the toolbar to remove the iTunes style status display; probably not exactly what you want, but can regain the entire toolbar’s worth of space that way.

    well, those are some of them. I found myself hating it but after 3 weeks of Xcode 4 on my MBA and 3.2.6 on my iMac I found myself wanting Xcode 4 on my iMac and so upgraded the whole system etc to get there.

    That’s not to say there aren’t too many problems, but it’s an ambitious jump forward that just isn’t done yet.


  2. Gwynne Raskind Post author

    a) I’m aware of the behaviors settings, but they’re completely inadequate, especially against the larger background of it being windows I want to control, not panes

    b) I still miss the pretty hierarchical visual diagram, the “class model”

    c, e) That only works if the tests are on an application target; if they’re on a static library or framework target, no dice.

    d) Deleting a repo only lasts until the project in question is reopened (including when Xcode is restarted). It then reappears in the Organizer immediately.

    f) That hides the one control in the toolbar I DO use – the scheme popup. And the status display is a replacement for the status bar, the information in which I do need to be able to see.

    It almost seems sometimes as if any effort to fix the problems (whether by me or by Apple) only makes them worse.

    1. Dad

      Ok. good counter-points :-) Software is difficult, and as the applications get more complex it only gets more difficult to present all the power to the user(s). I remember when Mac OS (pre OS X) had a rule of “no hidden commands – users can find *everything* the app does easily” and now we have all these menu items that switch meanings when modifiers are held down (very rare prior to Mac OS X), and Xcode has many hidden command keys – they very thing that Apple used to look down it’s nose at DOS and Windows for! ironic.

  3. Martin Pilkington

    A few comments:

    1. All your problems about switching back and forth between various views is solved by the assistant editor (doubly so given you have a 27″ screen where this works really well).
    2. The debugger can be put in a separate window. Create a new tab and name it something like “debug”, extend the debugger to the full height, drag the tab out into its own window and then create behaviours to show the “debug” tab whenever you want. Xcode should remember that it’s in a separate window.
    3. Schemes are designed to solve all the faffing about switching configurations and such that made Xcode 3 such an error prone tool to build with. If you want to build with a certain configuration then build for a task with that configuration. Usually you can do this by doing Product > Build For > Running to build a debug build and Product > Build For > Archiving for a release build.
    4. Guard malloc, zombies etc can be enabled in the diagnostics tab of the run task of your scheme.
    5. Your debugger for testing can be changed from the test task of your scheme.
    6. Compiling a single file (like things such as Zerolinking) isn’t really needed any more. LLVM is incredibly fast and Xcode finds errors as you type and incrementally builds anyway.
    7. The class model view is gone which is a bit of a shame, but it was rather sluggish and produced poor layouts. For those times I’ve needed to get a visual representation of a class tree I’ve found it far better to drag the Xcode project into OmniGraffle.


Leave a Reply

Your email address will not be published.