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?).

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

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

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:

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.

1 Comment