It’s not that Objective-C doesn’t have test frameworks. There are several: OCUnit (bundled with Xcode), GHUnit, Cedar and Kiwi. Cedar and Kiwi use blocks to get close to an RSpec-like syntax, but there’s only so far it can go. Objective-C can’t match Ruby when creating a DSL, even with preprocessor abuse.

Fortunately, there is a way to write tests in Ruby and run them against Objective-C code: MacRuby. MacRuby is an implementation of Ruby 1.9 that compiles Ruby to LLVM bytecode and has full access to Objective-C frameworks. You can write full Mac desktop applications with it, but for this post I’ll simply use it to write test specs with RSpec for testing Objective-C classes.

In this post, I’ll walk you through how to install MacRuby, RSpec and how to set up your Cocoa (Mac or iOS) project to unit test with RSpec. These tests are analogous to model specs in Rails. We’ll be testing classes in isolation, not trying to recreate the Cocoa environment in order to test window or view controllers, etc.

A big caveat for iOS developers: MacRuby loads Objective-C code from a framework, but iOS targets don’t support building frameworks. What this means is that you don’t have access to the UI* classes in the code under test. This limits what you can test. Pure model classes (those without any external dependencies) will be fine. Theoretically, it should be possible to find the simulator frameworks and link against those, but I’ve been unsuccessful thus far. Chameleon might help if you want to dig into this further.

With that out of the way, let’s get started. If you haven’t already, download and install MacRuby. This places the macruby binary and other Ruby tools you’re familiar with (irb, gem, rake) in /usr/local/bin, with mac prefixes.

Then, install RSpec 2.5 (at present, there are problems running specs with 2.6).

$ sudo macgem install --bindir /usr/local/bin --format-executable rspec -v '~>2.5.0'

--bindir ensures the rspec script doesn’t overwrite one that might already exist in /usr/bin, and --format-executable adds the mac prefix to it, so it matches the other MacRuby-provided scripts.

In Xcode, open your project and create a new target (File -> New Target). Use the Cocoa Framework template, found under Mac OS X, Framework & Library. Call it whatever you like. I used “Specs”. Do not use Automatic Reference Counting. MacRuby, like MRI Ruby, is garbage collected and will use the Objective-C garbage collector. If your project uses ARC, that’s OK. retain, release and autorelease are no-ops under GC, and nothing changes if the calls to them are missing in the first place. Include Unit Tests should also be unchecked.

You must adjust some build settings for the new target. Under Apple LLVM Compiler – Language, find the settings for Objective-C Automatic Reference Counting and ensure it is set to NO. Just below that, set Objective-C Garbage Collection to Supported.

Go to the target build phases, and add the .m files you wish to test to the compile sources phase. As you add files to your project later, be sure to check the boxes for both your main target and the Specs target if you want to test the new code.

Finally, you need to configure the schemes for the new target. In the build scheme, check the run box. In the run scheme, choose /usr/local/bin/macruby as the executable to test.

Set up the arguments to pass to the executable when it runs as follows:

Choose your framework as the base for expansions. You’ll pass two arguments to the program: the path to the RSpec wrapper and the directory containing the specs.

You might wonder why we’re using MacRuby as the executable to test instead of RSpec directly. If you try to use RSpec, Xcode won’t recognize it as a 64-bit executable and will refuse to run it under the debugger. It will work, but you must also choose “debugger: none” and give up your breakpoints, etc.

With this new target you get a new top-level group in your project. Xcode has also created Specs.h and Specs.m, which we don’t need. You should delete them.

Create a new file in this group called spec_helper.rb and paste this in:

framework 'Specs'
 
# Requires supporting ruby files with custom matchers and macros, etc,
# in spec/support/ and its subdirectories.
Dir["#{ENV['SRCROOT']}/Specs/support/**/*.rb"].each {|f| require f}
 
RSpec.configure do |config|
  # == Mock Framework
  #
  # If you prefer to use mocha, flexmock or RR, uncomment the appropriate line:
  #
  # config.mock_with :mocha
  # config.mock_with :flexmock
  # config.mock_with :rr
  config.mock_with :spec
end

At this point, you should be able to choose your new target from the scheme picker in the toolbar and run. We haven’t created any specs yet, so you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1636 thread 0x0]
No examples were matched. Perhaps {:if=>#<Proc:0x4007553a0 (lambda)>, :unless=>#<Proc:0x400795b60 (lambda)>} is excluding everything?

Finished in 0.0331 seconds
0 examples, 0 failures
Program ended with exit code: 0

You may not see any output. You can use ⌘7 and look at the most recent log or use this tip from Martin Pilkington to create a new window for output. I find this much less intrusive than allowing Xcode to constantly pop up the debugging panes in my editor windows.

Let’s create a simple spec file. Assuming you added a .m file that implements a class called Foo, create a new file in your Specs group called foo_spec.rb:

require "#{ENV['SRCROOT']}/Specs/spec_helper"
 
describe Foo do
  it { should be_an_instance_of(Foo) }
end

Run again and you should see this:

GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Mon Aug  8 20:32:45 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys004
[Switching to process 1796 thread 0x0]
.

Finished in 0.40422 seconds
1 example, 0 failures
Program ended with exit code: 0

It works! Now try adding breakpoints, mocking and stubbing objects, etc. You have all the features of RSpec available to you.

With 109 sessions to choose from, newcomers may not know where to start. This guide is intended to help you get started.

The Keynote: the only WWDC session not under NDA, this is where all the public news was announced. If for some reason you haven’t watched it yet, it’s worth watching, although it is a bit long and by now you’ve probably heard about everything.

Since everything else is under NDA, I can’t discuss specifics about the content of sessions.

Start with the Apple Platforms Kickoff. Where the keynote is truly for the press, this session is for developers.

Whether your focus is on Mac OS X or iOS, you’ll be using Xcode, so move on to Session 300: Developer Tools Kickoff. You’ll learn about the new tools and features coming in future versions of Xcode.

The final kickoff session is Session 400: Graphics, Media, and Games Kickoff. I found this session to be less focused on new stuff and more a general overview of the available frameworks and tools, though the demo at the end is impressive. There is a bit about Game Center and AV Foundation if you’re interested in these frameworks.

Trivia: in previous years, these sessions used the “State of the Union” moniker.

Where to next? That depends on what you want to do. Many sessions include pointers to others covering specific topics, so be sure to watch for those to find more information about areas that interest you.

If you’re a Mac OS X developer…

If you have an app in the Mac App Store or plan to ship one in the future, start with Session 203: Introducing App Sandbox and Session 204: App Sandbox and the Mac App Store. There are new submission requirements coming with 10.7 that are more important than anything else.

Follow that up with Session 101: What’s New in Cocoa. This is the high-level session to learn about the new stuff for developers in 10.7. Don’t miss Session 323: Introducing Automatic Reference Counting so you can (mostly) stop thinking about manual memory management.

Session 127: Design Patterns to Simplify Mac Accessibility is James Dempsey’s annual talk that includes a song. Even if you don’t think you care about accessibility (hint: you should), his talk is great and the song is a funny distillation of the topic.

If you’re an iOS developer…

Start with Session 100: What’s New in Cocoa Touch, then Session 323: Introducing Automatic Reference Counting, followed by Session 309: Introducing Interface Builder Storyboarding and Session 102: Implementing UIViewController Containment. Follow the suggestions for related sessions depending on your interests and needs.

App Design

Excellent design will set your app apart from the crowd. There are two sessions covering UI and UX topics: Session 110: Designing User Interfaces for iOS and Mac OS X Apps and Session 105: Polishing Your App, the latter of which includes non-visual polish such as responsiveness and performance, a user experience issue.

Security and Performance

You should care about the security of your app and how well it performs. Session 202: Security Overview discusses attack vectors and options for addressing them. Session 310: What’s New in Instruments will point you in the right direction for performance analysis and tuning, while Session 312: iOS Performance and Power Optimization with Instruments and Session 318: iOS Performance in Depth teaches practical techniques for diagnosing and fixing problems for iOS apps.

Releasing these videos for free is a great service to the Apple developer community. There is value in almost every session, and the huge advantage we have in watching them now is we can check out topics we might not have made time for if attending the conference in person. Skip ahead or stop a video if it isn’t holding your attention.

My recommendations here are a starting point. Apple’s platforms are growing and getting better every year. Explore new things; you never know when you might learn something relevant to an existing project. Watch a session about a topic you think you know well. With such a rich set of frameworks, there are often little tricks to learn that mean you can rewrite some old code to be clearer or perform better.

Is there a particularly good session I haven’t mentioned? Mention it in the comments!

I’ve been moving toward Git for more of my work, for mostly two reasons. The first is that Subversion uses “@” to denote a specific revision of a file, which makes adding images for the Retina Display annoying because they use “@2x” in the file name. The second is that integrating third-party source into a project is more work than it should be because Subversion litters the tree with .svn directories. I can’t simply delete the old third-party source and drop in the new files, because Subversion loses its state. Yes, I could svn rm, then svn add, but that grows the repository unnecessarily and I lose the ability to diff the source and see what actually changed.

Git does not use a numeric repository version, however, and a simple SHA1 hash is unsuitable for use as the third component of a bundle version because it can include the letters a-f. I took the simplest way out and use a file (build-counter) with a number in it, incremented for every Ad Hoc and App Store build, but not for Debug or Release. This file is created if it does not exist and automatically committed.

As with my Subversion script, if any local modifications are detected during an Ad Hoc or App Store build, it will fail.

Since it’s likely that Apple will enforce the same format restrictions on Mac App Store apps, this script can also be used in those projects.

# Xcode auto-versioning script for Git by Steve Madsen.
# Adapted from Subversion script by Axel Andersson.
 
build_counter_file = 'build-counter'
 
raise "#{$0}: Must be run from Xcode" unless ENV['BUILT_PRODUCTS_DIR']
 
def development?
  ENV['BUILD_STYLE'] !~ /Ad Hoc|App Store/
end
 
def local_modifications?
  `git ls-files -m` != ""
end
 
build_counter = File.read(build_counter_file).to_i rescue 0
unless development?
  raise "#{$0}: local modifications present for a production build!" if local_modifications?
 
  build_counter += 1
  File.open(build_counter_file, 'w') { |f| f.printf "%d", build_counter }
  unless system "git commit -m 'increment build counter' #{build_counter_file}"
    raise "#{$0}: Git commit of #{build_counter_file} failed: #{$?.exitstatus}"
  end
end
 
info = "#{ENV['BUILT_PRODUCTS_DIR']}/#{ENV['WRAPPER_NAME']}/Info.plist"
info_xml = `plutil -convert xml1 '#{info}' -o -`
raise "#{$0}: reading Info.plist failed: #{$?.exitstatus}" unless $?.success?
 
info_xml.gsub! %r{([\t ]+CFBundleVersion\n[\t ]+\d+\.\d+).*?()}, "\\1.#{build_counter}\\2"
 
IO.popen("plutil -convert binary1 - -o '#{info}'", 'w') { |plutil| plutil << info_xml }
raise "#{$0}: writing Info.plist failed: #{$?.exitstatus}" unless $?.success?

I stumbled on Daniel Jalkut’s post about automatically stamping the Subversion revision into Info.plist and thought that might be a good way to go. I also created a new key in Info.plist, LYSApplicationDisplayVersion, that I use as a human-friendly version string, which is where I get my preferred “1.0 b1″ form. CFBundleVersion now takes the form of major.minor.revision, where major and minor are the important parts of the human-friendly version (“1.0″) and revision is the Subversion revision number that produced the binary.

I like this method because it solves one problem raised by commenters on Daniel’s post. Because the Subversion revision is the third component, it doesn’t matter that r3999 is a mature 1.2 point release and r4000 is a risky pre-2.0 alpha for testers. Those versions end up 1.2.3999 and 2.0.4000 and it’s clear that they are from two different branches of development. For iPhone Ad Hoc distribution, iTunes also parses the version properly and knows that 1.0.100 is newer than 1.0.95.

Here is the script to paste into your custom script build phase:

# Xcode auto-versioning script for Subversion
# by Axel Andersson, modified by Daniel Jalkut to add
# "--revision HEAD" to the svn info line, which allows
# the latest revision to always be used.
 
use strict;
 
die "$0: Must be run from Xcode" unless $ENV{"BUILT_PRODUCTS_DIR"};
 
# Get the current subversion revision number and use it to set the CFBundleVersion value
my $REV = `/usr/bin/svnversion -n ./`;
my $INFO = "$ENV{BUILT_PRODUCTS_DIR}/$ENV{WRAPPER_NAME}/Info.plist";
 
my $version = $REV;
 
# (Match the last group of digits and optional letter M/S/P):
 
# ugly yet functional (barely) regex by Daniel Jalkut:
#$version =~ s/([\d]*:)(\d+[M|S]*).*/$2/;
 
# better yet still functional regex via Kevin "Regex Nerd" Ballard
($version =~ m/(\d+)([MSP]*)$/) && ($version = $1);
 
die "$0: No Subversion revision found" unless $version;
die "$0: Modified, switched or partial working copy, you sure about that?" if $2 && ($ENV{"BUILD_STYLE"} eq "Ad Hoc" || $ENV{"BUILD_STYLE"} eq "App Store");
 
open(FH, "plutil -convert xml1 \"$INFO\" -o - |") or die "$0: $INFO: $!";
my $info = join("", <FH>);
close(FH);
 
$info =~ s/([\t ]+<key>CFBundleVersion<\/key>\n[\t ]+<string>\d+\.\d+).*?(<\/string>)/$1.$version$2/;
 
open(FH, "| plutil -convert binary1 - -o \"$INFO\"") or die "$0: $INFO: $!";
print FH $info;
close(FH);

There are a couple of other changes to this script for Subversion 1.5 and later, and for iPhone OS targets.

The first is that the regular expression allows for a trailing P in the Subversion revision. This signals a working copy from a sparse checkout, which I never use and therefore may be a problem. I have the script fail if any letter is appended to the revision when the BUILD_STYLE is “Ad Hoc” or “App Store”, which are two new configurations, cloned from Release, that I use for Ad Hoc and App Store distribution, respectively. Especially for modified working copies: I never want to accidentally hand out a build made from a modified working copy. Should the day come that I really do, I can comment this line out, make the build, and uncomment it again.

The second is that iPhone projects convert Info.plist to the binary plist format in the application bundle. In order to extract the existing CFBundleVersion key, it must be converted back to XML. When writing the plist back out, it is again converted to binary. Both of these steps use plutil, which is part of the Developer Tools.

The second is code completion for language constructs such as if statements. Xcode wants to do this:

if (condition) {
}

While I used this style a long time ago, today I want the opening brace on its own line:

if (condition)
{
}

No amount of digging in the preferences will provide a way to change these behaviors, however there is a lot of customizability hidden in the Xcode User Defaults. My two issues are solved quite easily:

$ defaults write com.apple.Xcode XCShowUndoPastSaveWarning NO
$ defaults write com.apple.Xcode XCCodeSenseFormattingOptions -dict BlockSeparator "\n"

target specifies product type ‘com.apple.product-type.tool’, but there’s no such product type for the ‘iphonesimulator’ platform

There is no perfect solution to this problem, but here’s my workaround: rather than let Xcode build the dependent project for me, I simply added a call to xcodebuild as part of my custom script phase. As long as the input and output files for this phase are set up properly, the entire phase is skipped when the output file is up-to-date, and xcodebuild is pretty fast when the target binary is already built, too.

My final script phase looks like this:

(cd SubProject; xcodebuild -configuration Release)
SubProject/build/Release/SubProjectCommand