High Order Blog

We spend the vast majority of our time writing code in Objective-C for our iPhone applications. In my opinion, one of the biggest problems with iPhone or Mac development is Xcode. Yeah, it’s gotten progressively better over the years, but I still wonder how any developer can use it productively as their full-time development environment.

My weapon of choice for day-to-day iPhone development is Vim. Of course, at its core Vim is a text editor, not an IDE, so those looking to duplicate the functionality of more modern development environments in Vim have to either look to Vim’s rich plug-in ecosystem, or roll their own.

One of the first problems I wanted solved was to build my programs and fix compiler errors in Vim. I’m trying to minimize the number of times I need to switch between Vim and Xcode (in other words, reduce my Xcode use) as much as possible.

Xcode helpfully ships with a command line build tool called xcodebuild. It should be in your $PATH by default once you’ve installed the Xcode tools:

$ xcodebuild -help
    Usage: xcodebuild [-project <projectname>] [-activetarget]
          [-alltargets] [-target <targetname>]... [-parallelizeTargets]
          [-activeconfiguration] [-configuration <configurationname>]
          [-sdk <sdkfullpath>|<sdkname>] [<buildsetting>=<value>]...
          [<buildaction>]...
        xcodebuild [-version [-sdk [<sdkfullpath>|<sdkname>] [<item>] ]
        xcodebuild [-showsdks]
        xcodebuild [-find <binary> -sdk <sdkfullpath>|<sdkname>]
        xcodebuild [-list]

Vim includes the ability to build programs via make, and, more importantly for me, supports customizing the command-line builder is uses as its make program. All that’s needed is to configure Vim to use xcodebuild as our make program, instead of make, and we should be in business.

For xcodebuild to work properly, the command needs to be run from within the same directory as your .xcodeproj file, or it needs to be told where that file is located via the -project command line option. This is a problem for me, since I like Vim to set its working directory to the directory of the file I’m editing, which is never the same directory that contains my .xcodeproj file. Since my current directory can’t be relied upon, I needed to find a way to dynamically locate the .xcodeproj file in order to correctly trigger a build.

Enter Rake. Anyone whose ever done any Ruby programming is probably familiar with it, and if you’ve never heard of it, I encourage you to check it out. I like to use Rake for simple project automation, including updating my tags file and performing certain git operations.

One feature of Rake that came in handy for solving this particular problem is that when rake is typed at the command line, it will recursively search up your directory tree looking for a Rakefile. That means if I execute Rake from within foo/bar/baz, and my Rakefile is in foo, Rake will find it and run it correctly.

Taking advantage of this, I’ve set up a build task within my project’s Rakefile that will perform the default Xcode build (which is configured within the Xcode project itself) via xcodebuild. The relevant Rakefile snippets looks something like this:

def project_file(root_dir='.')
  Find.find(root_dir) do |f|
    if f =~ /\.xcodeproj$/
      return f
    end
  end
  nil
end

def xcodebuild
  "xcodebuild -project #{project_file}"
end

desc 'Build the default target using the default configuration'
task :build do |t|
  puts %x{
    #{xcodebuild} |
    grep -v "note: This view overlaps one of its siblings ."
  }
end

task :default => [ :build ]

Note that I have to search for my .xcodeproj file because our project structure conventions have it living in a subdirectory of the project root, and I don’t want to hardcode the path or the project file name for project portability reasons. Note also that piping the output through grep is a hack to suppress annoying Interface Builder warnings that I can’t figure out how to shut off in IB or Xcode. If anyone knows how to do this, please share.

Now all you have to do is invoke your Rakefile from within Vim by setting Rake to be your make program by typing:

:set makeprg=rake

Now when you type :make from within Vim, it’ll invoke Rake. If your working directory is within your project’s root directory, Rake will search for your Rakefile, and, when it’s found, invoke the build task. You can also pass arguments to the make command within Vim, so you’re not restricted to running a single Rake task with no arguments.

Since Xcode uses GCC to compile iPhone programs, Vim can already parse the compiler’s output and make sense of compiler warnings and errors. This allows you to navigate to those warnings and errors From within Vim using the standard cnext and cprevious commands.

To load the build output as a Vim window that spans the width of the frame underneath any other windows (important for me as I like to run Vim with two vertically split editor windows and a NERDTree window to the left of those), just type :botright cwindow.

I also set this configuration automatically whenever I edit an Objective-C file via my .vimrc file:

autocmd FileType objc set makeprg=rake

That’s my setup. I hope it helps more people get out of the swamp of Xcode and into an environment that’s actually productive. And of course, any suggestions for improvements, or other tips or tricks, are always welcome.

One of the first things many users of Xcode want to do is customize the file templates used to generate stubs for classes and other items in your project. We’re spending most of our time building iPhone applications, so we’re interested in customizing the Cocoa Touch templates.

Losing __MyCompanyName__

Getting rid of the __MyCompanyName__ placeholder is almost always the first thing people want changed when they start using Xcode. This can be done in one of two ways.

Set Your Company in Address Book

Definitely the simplest method: just set the company field for your personal card in Address Book.

Set Your Company Manually

You can set your company manually by running the following command in your terminal:

$ defaults write com.apple.Xcode PBXCustomTemplateMacroDefinitions \
  '{"ORGANIZATIONNAME"="High Order Bit";}'

Customizing Cocoa Touch Templates

You’ll save a lot of time over the long term with a bit of up-front investment configuring Xcode with your own templates.

You can find the standard Xcode Cocoa Touch plugins here:

/Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/
    File Templates/Cocoa Touch Classes/

Each directory with the extension .pbfiletemplate is its own template.

You don’t want to edit these files. While doing so will work, the next time you install Xcode, your changes will be overwritten. Instead, you should place your custom templates within your home directory (create these folders if they don’t already exist):

~/Library/Application Support/Developer/Shared/Xcode/File Templates

Inside the File Templates directory, your templates must be placed in a Cocoa Touch Classes directory. This directory can either sit directly within File Templates, or you can create subfolders to further group your templates. For example, I’ve created a High Order Bit subfolder where the templates include our standard comment header and the boilerplate code is formatted per our coding conventions.

We’ve also added to the list of available templates, adding one for creating new protocols and another for creating class categories. Creating new templates is pretty self-explanatory once you crack open the .pbfiletemplate folder contents.

We keep these templates in source control. I want Xcode to pick up changes automatically when I pull from our repository, and I want to easily share any local changes I make. I could just clone the repository into the Xcode File Template directory, but I prefer to keep them in the directory where I keep the rest of my source code and create a symbolic link to this location where Xcode expects it:

$ ln -s $HOME/src/xcode-configuration/File\ Templates/Cocoa\ Touch\ Classes \
  ~/Library/Application\ Support/Developer/Shared/Xcode/\
  File\ Templates/High\ Order\ Bit/Cocoa\ Touch\ Classes

Done! Your own custom Xcode Cocoa Touch templates, tracked and shared in source control.