Optimizing My XCode Workflow

XCode is a powerful beast, but sometimes it feels a bit long in the tooth compared to some other modern IDE’s. And it definitely doesn’t seem to have had that fine attention to an all-in-one layout design a la Aperture 2.

Sometimes it feels like there are XCode windows scattered all over my office and I need to dig around to find them. And the XCode Preferences window is, well, it feels old. There are some changes to the default config that can help, however.

Currently I’m using the Condensed Layout (In Preferences…General). That keeps the Files/Targets/Other browser in a separate window which I tuck off to the side.

Then when I open the first file in a new project I click the Grouped icon on the toolbar. This causes further file openings to be in the same window instead of a new one (why, XCode, oh why, do you not have tabs for open files?).

xcode_grouped.png

You can switch between open files with the open file list (which can be opened with CTRL-1 as well):

open_files.png

Another setting I like to fiddle with is automatic visibility of the Build Results window. These are the settings I use (Preferences…Build):

build_results_prefs.png

Enabling Open During Builds isn’t really necessary, but I find it comforting to see the build and unit test messages going by. What is critical is to have the Build Results open On Errors or Warnings and to close if there are No Errors or Warnings. In this way, your Build Results window will be open and ready to help if your have introduced any warnings (yes you should fix them) or errors into your build.

I love and hate the message bubbles, but I do have them enabled for now.

I also enable the Always Save option in this Preference Pane:

always_save_pref.png

If I’m starting a build (usually with Cmd-B) then yes, I want to save any unsaved files. In my mind this behavior should be the default so I enable it here.

Finally, just to avoid any temptation that I might feel to not fix a warning when it appears, I check off the Treat Warnings as Errors box in the Build tab for my executable’s target. Especially in Objective-C, warnings can be telling you about a big error that you just built, but that Objective-C is willing to give a chance. Be sure to understand and eliminate them all.

warnings_as_errors.png

Subscribe to my RSS feed!


1 Comment

Personally I think “Treat Warnings as Errors” should be on as a default when creating new projects. If you’ve never used the setting, it may feel like a nuisance at first, but it is worth doing.

Posted by Matthieu Cormier on 12 April 2008 @ 6pm

Leave a Comment

Cocoa Warning: from distinct Objective-C type iTunes Scrollbar with Core Animation