Monthly Archives: February 2012

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:

Missions of the Reliant: Back on the Radar!

It’s been a long time since I made any meaningful posts about Missions of the Reliant, but here I am at last to tell you all that I haven’t abandoned it! First before anything else, thanks to everyone for your exemplary patience with me over the last year or so with no word.

Coming back to the code after all this time and with the experience hard-won in other code, I can see that in the past I was both absolutely brilliant and somewhat stunted :). However, most of the issues that I see have more to do with the code having been originally designed when Leopard was the latest and greatest OS; the technically inclined among you will remember with horror the days of no libdispatch, libcache, libclosure, ARC, or ZWRs. I say without shame that a lot of problems I’ve had (and a few that still exist) would never have happened if I’d had ARC to work with from the beginning.

This brings me to the secondary point of this post – Missions will be the better (and the more quickly completed) for an ARC migration. ARC is supported on Snow Leopard, but one of its most powerful features, Zeroing Weak References, works only on Lion. I had this same debate when SL itself came out, and I’m faced with it again: Am I comfortable with limiting Missions to working only on Lion?

So here I am, asking for the opinion of the loyal followers of this project again, with it kept in mind that I’m working on the code either way: How many of you would be left out by a Lion requirement? (And, more amusingly, how many of you would upgrade to Lion at last just to play!? :)

I’d like to say thanks again to everyone who’s bothered themselves keeping up with my near-silence over the time since I started working on this port. I’ll post again as soon as I have the project building in Xcode 4 (yes, it’s been so long since I touched it that I have to retool it for a whole new Xcode version!). Until then, happy space flights to you all!