How to Make Xcode’s UI Work for You
Now, with most applications that support a tabbed interface, each tab is typically used to hold a single document, so that you can switch easily between them. I tried this with Xcode 4, but quickly found that the set of files I’m working with at any given time is usually too large for tabs to really be an effective way of managing them. The number of tabs would quickly grow to where I couldn’t find anything, and didn’t end up saving me any time. The key realization I had was that, rather than having one tab per file, I should instead have one tab for each type of task, such as editing, building, debugging, and so forth.
I liked certain aspects of Xcode 3’s user interface better, and there are some surprising omissions, but overall I don’t have a problem with the changes in Xcode 4. In many ways, it’s an improvement. Rather, the problem with Xcode 4 is that it’s been shipping as a non-beta version for over a year now, and yet it still has the reliability of beta software. Aside from later versions of Xcode 3, Xcode was pretty much always more crashy and error-prone than Apple’s non-developer apps. So was Project Builder. (The older ProjectBuilder, sans space, seemed solid to me, and it had some nice features that still haven’t made it into Xcode.) And on the classic Mac OS, Metrowerks CodeWarrior suffered from similar problems at times. (As I recall, THINK C was stable, but I didn’t do much Mac development in those days.)
Developers are people, too. If the quality isn’t good enough for iTunes or Safari, it shouldn’t be acceptable for the tools used to developer those applications. Or, for that matter, the third-party applications that we rely on.
