iOSDevCampDC 2014 Coming in August!

Mark your calendars: the date for iOSDevCampDC 2014 will be Saturday August 2 Friday August 1, 2014. We’ve booked a big place this year for iOSDevCampDC 2014 – the new DIG space at Capital One in Tysons Corner. It will follow the same one-track format, although we’re thinking of having some more time in-between sessions so we can enjoy the game room. I hear foosball and air hockey are good for learning. :)

We’ve also issued a Call for Speakers, ending on March 28th, so if you’re interested in speaking, send us a talk proposal with what you want to present, a short bio and link to your Twitter (or other) profile to We would love to have at least one female speaker especially. Natalia presented along with Keith and Kiril about Harbor Master back at iPhoneDevCampDC and she was well received.

If you are interested in attending, please stay tuned and follow @iosdevcampdc on Twitter. We’ll likely be opening up early bird ticket sales sometime in April.

Preparing an iPhone for power outages

We just survived Hurricane Sandy here in the Washington DC area. We were fortunate that we did not get more damage in this area. The Derecho in June seems to have prepared the area. However, I wanted to be prepared this time and I wanted to make sure I could use my iPhone if the power went out.

I have a few devices available to me: I was going to use an iPhone solely for emergency calls. I prepared a 5th gen iPod Touch for listening to audio books and reading social media while my WiFi stayed up. I saved the iPad and my Android devices for entertainment. I still also have a landline, but you never know if you will have to leave your house in a disaster and then you’ll really want your smartphone with you.

So how can you prepare an iPhone for emergency calling usage? (Note that while I’ll be discussing iPhones, this applies to Android phones too, but the setting names will be different.)

The primary concern I had was battery life. I’m currently using an iPhone 4S and it has a reputation for not having a long lasting battery. However, I was determined to make it last and preferably for several days in case the power were to go out for that long.

I prepared my iPhone at 3:30PM on Monday when the storm started picking up. On 3:30PM Tuesday, the worst was over. I had made one 6 minute phone call to change an upcoming hotel reservation. In 24 hours, the battery had only gone from 100% to 95%. At that rate, the iPhone would last for approximately 20 days.

Full battery

Here’s the steps I took to prolong my battery life (all of these are found in the Settings app):

  • Location Services: Off. You won’t be able to use Find My Phone, but that’s not really your top priority in an emergency since you’ll likely keep a tight leash on your phone. This relies on GPS which is a big power drain for phones.
  • Wi-Fi: Off. WiFi takes less power than GPS, but it still is a drain especially if you have background services like iCloud, which do work even when you’re not using an app. Use another device for WiFi if you need it. Better yet, get a battery-powered AM/FM radio to get news during emergencies.
  • Brightness: All the way to the left. Screens use a lot of power, but you save power by setting it to the dimmest setting.
  • General > Network > Cellular Data: Off. 2G, 3G and LTE all utilize power, with the newer technologies using the most. If you need to leave the house, then I’d turn this on when you need it.
  • General > Usage > Battery Percentage: On. This provides a nice percentage next to the battery icon to let you know how much battery you have left.
  • General > Bluetooth: Off. Yes, bluetooth uses power too.
  • General > Auto-Lock: 1 Minute. For the most power savings, turn off the screen manually when you’re done using your phone. However, this will make sure you don’t leave it on for more than a minute.

Why not just enable Airplane Mode, you say? It turns off all of these, but it also turns off cellular voice, which defeats the purpose of having an emergency smart phone.

iOSDevCampDC 2012

About two weeks ago, on Saturday August 11th, we held our fourth iOS-related event in the Washington DC area: iOSDevCampDC 2012. We had a great mix of talks, six in all, from local iOS experts, with a select group of sponsors and a great group of attendees. Verisign hosted us and provided the venue in Reston, VA, allowing us to accommodate more people than last year. The dual screens were a nice touch too.

Let me give a brief wrap-up of the talks:

Ken (chief doer of savvy apps) gave a talk about how gestures affect the designs of iOS apps.  He talked about some good lessons learned.  I was impressed that he mirrored both his iPhone and iPad on his Mac so that he could project both on the screen.  Ken’s definitely been a proponent of gestural (or gesture-first) interfaces with apps like Agenda.

Jon (DC area Managing Director of Big Nerd Ranch) dived into the technical details of concurrency on iOS.  He covered both GCD and also NSOperation.  I hear he’s going to be giving an OpenGL class soon.

Mark (Director of Mobile Development at Politico) discussed how to make iOS apps more flexible by having them adapt to changes via a dynamic configuration that’s downloaded.  He also showed some good practices around that such as validating the configuration and having a good download manager.

Mark (Senior Lead Developer at Odyssey Computing) showed us how to do slick animations to do things like folding screens like origami and flipping screens like a book. I really liked that he wrote an app that allows you to toggle some switches and sliders to try out different permutations to see how they affect the animations.  He blogged about his experiences and his presentation titled “Enter the Matrix.”

Chris (Director of Strategy, Global Monetization Solutions at Millennial Media) explained how to use metadata to make more money with ads.  The more you know your users, the better the ads you show them will be.  One point that stood out was tangential: every app needs a privacy policy.  This is due to many forces in our industry but is probably going to be forced in the near future due to government oversight.

James (Principal Software Architect at YellowBrix) took us through how to embed Lua, a dynamic scripting language, into iOS apps.  He also discussed his open source framework for making it easier to do Lua in iOS called Gemini.

As the Lead Organizer of iOSDevCampDC, it was satisfying to put together another event and have it go well.  Sean was a great help as a fellow Organizer, heading up the delicious food that we all savored and assisting with countless other things.  Jose helped out as well, taking pictures and also giving a good overview of our local weekly (NSCoderNightDC) and monthly (CocoaHeadsDC) get-togethers.  My kids Diego and Mateo manned the registration booth and got a taste of what professional developers do. They’re getting started with programming themselves.

Special thanks to Happy Apps, Millennial Media, savvy apps and Verisign for sponsoring the event!

C4[3] Blitz Talks and MacRuby

I just came back from C4[3] – an Independent Mac and iPhone Developer Conference in Chicago. Wolf and Victoria host it and I saw Daniel Jalkut helping out along with a few other folks. In case you’re not hip to the zero numbering scheme, this is actually the 4th iteration of the conference. I went last year to C4[2] and this year was even better in my opinion.

There’s too many things to write about so I’ll just focus on two things that stick out in my mind: Blitz Talks and MacRuby.

I go to NSCoderNightDC and we have a nice core group of Mac and iPhone Devs who show up every week and eat Strawberry Napoleons. We also code and talk about design. Well 3 of the guys proposed Blitz Talks and got accepted.

Rob hit it out of the park with his Briefs iPhone prototyping tool. Jose actually created a Brief on the way from the airport to the hotel. He was kinda nervous beforehand in the hotel room but he practiced his presentation a few times on me and was really well prepared. His slides were top-notch but I think the idea is what really captivates people. I’m personally a big fan of fake-powered prototypes – prototypes powered by objects that return canned responses, but I’m definitely going to try out Briefs on upcoming iPhone engagements.

Jose did well with his presentation about the different types of contexts that an iPhone user would use different apps in. I’ve seen him give this talk before so it was interesting to see how he pared it down to fit in the much tighter 5 minute time frame.

Mark gave an interesting talk about how to do video right for Mac and iPhone screencasts and demos. I have a lot to learn about this and I’m hoping to work with Mark on a screencast sometime in the near future for Webnote.

There were many other Blitz Talks and I think they really were a nice Change of Pace that I haven’t seen in other conferences. Wolf amped it up even further by providing an animated radar / pie that kept filling up as the talk progressed.

MacRuby was the other big surprise for me. I had been tracking RubyCocoa and had seen the early MacRuby demo at RubyConf 2007. I’m a former Smalltalker and current Rubyist. I do all my automated build processes in Ruby and I’ve also created various non-Rails Ruby server-side components for clients. Plus I did Ruby on Rails for a few years. So I’ve been wanting to make Mac apps with Ruby, except one thing kept holding me back: I don’t want to show everyone my source.

Obfuscation is not a problem with server-side Ruby. The users only see what you expose via the web or other ports. They only see what’s rendered to them or the API that you expose.

Client-side Ruby is another world altogether. Users learn that they can peek inside application packages and if you’re writing Ruby, they can see your source. I’ve asked this question at WWDCs in the past and the answer was usually that its not a big deal and that you should just keep innovating. But we don’t just leave our Objective-C sources lying around, do we?

MacRuby will soon solve that, or I hope it will, with his AOT (Ahead Of Time) compiler. Or as it is known in the C/C++/Objective-C world: a compiler. LOL. So with the AOT, we will be able to write Cocoa apps in Ruby, compile them and run them on Mac. (And maybe iPhone – the jury is still out on that.) Which means that people can’t just look at your Ruby source. Even better, there is the HotCocoa project which provides useful macros / shortcuts for common Cocoa idioms.

Why use Ruby to write Cocoa apps? Ruby can be more concise, there are more libraries to choose from and the testing/mocking frameworks are better. On the other hand, the debugging story is still hazy.

I’ll be trying out MacRuby soon and I’ll post what I find. They’re currently at 0.4 with a 0.5 on the horizon, with nightlies for Snow Leopard available and the latest source available in both Subversion and Git.

iPhoneDevCampDC is coming July 31st – August 1st!

We are putting together a local gathering of iPhone developers in the Washington DC area. Its called iPhoneDevCampDC and it is a satellite event of the main iPhoneDevCamp (which is in Sunnyvale, CA.) There are satellite events all over the country and Washington DC is one of the new ones in this third iteration. iPhoneDevCamp Florida, by the way, is another new one – go East Coast!

iPhoneDevCampDC is going to be the evening of July 31st and then all day August 1st. We are looking for sponsors for the event, so if you are looking to get your company in front of iPhone developers, please contact us.

We will be limiting the number of attendees this year to 50. Ticket registration will start next week around the beginning of July. This is a BarCamp-style conference, where the attendees present the sessions, so if you’re planning to attend, start thinking of what session you could present. We won’t have time for everyone to present, but if everyone comes ready, then we’ll have great topics for everyone to choose from.

There’s a website for iPhoneDevCampDC with some more details and we’ve also started tweeting at @iphonedevcampdc, where we’ll publish news about the event (like when registration starts.)

Three things I learned at WWDC 2009

I went to WWDC 2009 last week and I learned 100 things. Unfortunately, 97 of them are under NDA, so I’ll just share with you three things that aren’t secret.

1. When in doubt, file a bug.
Mac OS X and iPhone to some extent are a democracy, where bugs count as votes. Apple uses your bug filings to see which things should get fixed and which things should get implemented. I’d say at least half of the Q&A could be summed up by: “Please file a bug.”

At first it seems like the Apple Engineers are just passing the buck, but really what they’re saying is either:
a. “Yes that seems like a good idea, but I need you to file a bug so I can justify working on this, be it a bug or a new feature, to my manager.” or
b. “I’m not sure about that, but file a bug and if we get enough of those, we’ll work on it.”

BTW here’s how to file a bug in Apple’s Radar bug database.

2. Instruments is as important as Xcode and Interface Builder.
Every Mac and iPhone Developer is familiar with Xcode and Interface Builder. But Instruments is just as important, especially with the relatively limited hardware of the 1st gen/3G iPhone and 1st gen iPod Touch. There were a lot of good sessions that featured Instruments that are worth watching when the session videos come out.

Even on Mac OS X, profiling your application to improve its performance and memory usage is important to do with Instruments.

Another interesting tool to delve into is dtrace. Its the technology that underlies some of the instruments in Instruments.

Also I heard a new phrase “There’s an Instrument for that.” If you have access to the Snow Leopard betas (and you should get it via ADC), then check out the new ones that are available. If you don’t see one that fits your needs, you might consider filing a bug requesting it.

3. WWDC 2010 will hopefully occur in a bigger venue.
WWDC 2009 sold out the fastest as I’ve seen any (and perhaps the fastest ever?) 60% of attendees were new attendees. So there’s still another 3000 or so people who were at WWDC 2008 and previously that might have attended if they had purchased their tickets sooner. Add to that another 2000 or so developers that see the market growing due to the $99 iPhone and you’re over 10,000 developers that could be attending WWDC 2010. That’s roughly double the attendance.

OK I admit that I don’t really like lines and such, but the keynote line ran completely around the block back to the front! Moscone West was just overflowing with Mac and iPhone developers this year. I’m hoping that next year’s WWDC 2010 will be say in Moscone South or Moscone North. It might not be as cozy but it should give some breathing space and allow for more developers (including those who have longer purchasing cycles) to attend.

How to use TouchJSON in your iPhone Apps

I gave a presentation at NSCoderNightDC a week ago on “How to use TouchJSON in your iPhone Apps.” It was great fun and we had a little iChat Screen Sharing session going on with Rob aka @capttaco so that everyone could see.
TouchJSON Presentation First Slide

If you missed it, you can still get the slides: “How to use TouchJSON in your iPhone Apps“.
As an added bonus, I also uploaded the sample iPhone project which shows how to search Twitter using TouchJSON!

Pitfalls That You May Encounter when Running iPhone Unit Tests and How to Overcome Them

We have come to the last part of this series on iPhone Unit Testing. In this post we will cover pitfalls that you may encounter when running iPhone unit test and how to overcome each of them.

Pitfall: You may get this message in the Build Results: “Couldn’t register PurpleSystemEventPort with the bootstrap server. Error: unknown error code.

Overcome it by: This generally means that another instance of this process was already running or is hung in the debugger.”
If you get this, it just means that the iPhone Simulator is already running. Quit the Simulator and then run your tests again.

Pitfall: You get the error “Unable to send CPDistributedMessagingCenter message named SBRemoteNotificationClientStartedMessage to (ipc/send) invalid destination port”.

Open up the “Tests” target by double-clicking on it, go to the Properties tab and clear out the Main Nib File text field.

Pitfall: XCode is not executing any of your unit tests. Instead it hangs at the line: “Running 1 of 1 custom shell scripts…”

Open up your Tests target, go to the Properties tab and clear out the Main Nib field. Do a Clean All. Then Build and your tests should run.

Since we discussed clearing out the Main Nib text field twice here, I think we should discuss why this would work. It will give us insight into how the Google Toolbox for Mac unit testing framework operates.

What I think it is related to is the Main Nib loading and that Nib having an App Delegate which implements applicationDidFinishLaunching. This sometimes causes everything to not work because GTMIPhoneUnitTestDelegate’s applicationDidFinishLaunching not to get called – and this is what runs the tests. Clearing out the Main Nib field will cause this potential collision to not occur and GTMIPhoneUnitTestDelegate will function properly by finding and running your unit tests.

Have you had run into any other pitfalls while doing iPhone Unit Testing? If so, feel free to leave a comment here. I also encourage you to visit the Google Toolbox for Mac discussion group on Google.

Getting Started Writing iPhone Unit Tests

Alright, well hopefully you have read the first two parts of this series. If not, then go back and read Is iPhone Unit Testing Possible? and How to Create an iPhone Project in Xcode That Can Run Unit Tests.

Make sure that you have an iPhone Project that is already set up for unit testing. You can either follow the steps in those last two posts or you can download a pre-made “example1” iPhone Project that can run unit tests that I uploaded to GitHub.

In this tutorial, I will be showing you, the iPhone Developer, how to get started writing unit tests for your iPhone App. I will be doing this in the TDD style – where TDD == Test-Driven Development. In other words, we will write the tests first. You don’t have to do it this way, but I thought I’d show it to you since it is a nice practice that was ingrained in me from the Ruby on Rails community. This is not to say that it started in Rails – it really started back in the Smalltalk days with Kent Beck and the other original XPers (eXtreme Programming). But being involved in the Smalltalk, Java, Objective-C and Ruby communities in my career since 1995, I haven’t been seen such testing dedication as I have in the Ruby on Rails community. I hope it is something that really spreads in iPhone community as well.

So, how do we get started? Or in TDD-speak, how do we write our first failing test? You write failing tests first as sort of a TODO to yourself as a programmer. When you get it to pass, then you can mark off your TODO, but in a nice programmatic way.

You will need to create a Test Class. Then you’ll add a Test Method. This should reference a non-existent Class, which you’ll then proceed to flesh out. This is the classic Test Driven-Development (TDD) way of testing.

Create a new group with Project > New Group. Name this new group “Tests”.

Create a new Test Class with File > New File… and choose Cocoa Touch Classes / NSObject subclass.

Name your class “FooTest.m”. Make sure that it is only a member of the Tests target.

Run the tests now by pressing the Build button. Make sure that the “Tests” target is selected in the Active Target dropdown and “Simulator” is chosen a the Active SDK. Notice that the Test Class isn’t being included yet:

Test Suite '/Users/louie/builds/Debug-iphonesimulator/' started at 2009-02-19 14:43:32 -0500
Test Suite 'SenTestCase' started at 2009-02-19 14:43:32 -0500
Test Suite 'SenTestCase' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'GTMTestCase' started at 2009-02-19 14:43:32 -0500
Test Suite 'GTMTestCase' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite '/Users/louie/builds/Debug-iphonesimulator/' finished at 2009-02-19 14:43:32 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.001 (0.001) seconds

This Test Class doesn’t know it is supposed to contain tests yet. Let us change that.

Change the import statements to include “GTMSenTestCase.h” This is the Google Toolbox for Mac version of SenTestCase. This enables your test cases to be found by the GTM RunIPhoneUnitTest script. It also adds some additional capabilities we will cover later.

Change the superclass to be “SenTestCase.”

Your class header FooTest.h should now look like:

#import "GTMSenTestCase.h"

@interface FooTest : SenTestCase {



If you run the tests now, you’ll see that FooTest is now being included:

Test Suite '/Users/louie/builds/Debug-iphonesimulator/' started at 2009-02-19 14:44:30 -0500
Test Suite 'SenTestCase' started at 2009-02-19 14:44:30 -0500
Test Suite 'SenTestCase' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'FooTest' started at 2009-02-19 14:44:30 -0500
Test Suite 'FooTest' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite 'GTMTestCase' started at 2009-02-19 14:44:30 -0500
Test Suite 'GTMTestCase' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds
Test Suite '/Users/louie/builds/Debug-iphonesimulator/' finished at 2009-02-19 14:44:30 -0500.
Executed 0 tests, with 0 failures (0 unexpected) in 0.002 (0.002) seconds

However, with 0 tests, FooTest is pretty boring. Let’s spice up FooTest. Switch over to FooTest.m. You can quickly do this with the keyboard shortcut Command + Option + up arrow.

Now add a Test Method. Test Methods are where the work happens with testing. They must start with “test” and the first character of “test” must be a lowercase “t” in order to be found by the test runner script.

Add this piece of code:

- (void)testBar {
	Foo *instance = [[[Foo alloc] init] autorelease];
	STAssertEquals(@"bar", [instance bar], nil);

Try to Build. You’ll get 3 errors. They all relate to Foo not being declared in FooTest. This actually is good! Well, in the classic TDD sense. What we have done is written what we want to happen when a client calls Foo and what the client expects back when it calls the bar method of Foo. Specifically, we want it to return the NSString @”bar”. This can also serve as good documentation for future programmers who are inspecting this code to see an example of how to use Foo.

Now let us fix these errors:

Select the Classes group.
Create a new Class with File > New File… and choose Cocoa Touch Classes / NSObject subclass. Yes, this is just like how we created a new Test Class. They are the same because we haven’t created a new template for a Test Class.

Name your new class “Foo”.

Make sure that it is a member of both of the targets “example1” and “Tests”. The reason we want this is because Foo should exist in the main application but also should be available for testing. Going back, we can see that FooTest was only in the Tests target because we don’t want to ship our tests with the application. This will make it lighter and thus quicker to download when a user decides to purchase it from the App Store. Quicker downloads should mean a quicker path to riches! :)

Now try building again. Still 3 errors? Yes, because we need to make Foo known to FooTest.

Go to FooTest.h and add the line:

#import "Foo.h"

Now build again. You should have two errors now and four warnings.

Now Xcode tells you that “warning: ‘Foo’ may not respond to ‘-bar’.” Again this seems wrong, but this is actually a good thing with classic TDD. This just means that we need to declare the method bar. So let us do just that.

Go to Foo.h.

Add the method declaration:

- (NSString *)bar;

Go to Foo.m.

Add the method implementation:

- (NSString *)bar {
	return @"bar";

Now build and you have success! This is known in TDD-speak as “green bar.” When you had failures due to errors/warnings, that was “red bar.” This had to do with the graphical indicators of the tools at the dawn of TDD. We can just call them “success” and “having test failures.”

This method is what I’ve used over the past year to help ensure good code quality in that iPhone apps I have built for my consulting clients. At this point, you know enough to be able to write unit tests, the iPhone way with the help of Google Toolbox for Mac. You can start to use more generic unit testing techniques that you may have used in other languages. There are also some iPhone-specific testing techniques that I will cover in the future if people are interested.

How to Create an iPhone Project in Xcode That Can Run Unit Tests

This is the second part of a blog series I am writing on How to Do iPhone Unit Testing or Lessons Learned from Unit Testing iPhone Apps.

I am targeting this at iPhone Developers.  My aim is to take you step by step through the process of setting up an iPhone Project in Xcode that lets you run unit tests.  There are other guides out there but I’d like to make this very visual and easy.

So let’s get to the question:

How do I set up an iPhone project that lets me unit test my app?

Step 1:  Create a New iPhone Project

Create a new project via File > New Project.  Choose “View-Based Application” (you can choose any, but we’ll use this type here.)  Name your project “example1” to follow along with this tutorial.

After your project is created, it should look something like this:


The "example1" project after creation.
The "example1" project after creation.


Now that you have created the project, you can add the supporting files to enable unit testing.

Step 2: Create a Folder to Organize Your Unit Testing “Framework”

One of the lessons learned from my iPhone consulting is that iPhone projects can get big and messy.  It helps if you isolate your “frameworks” into folders in Finder.  I say “frameworks” loosely because you can’t really have Mac OS X-style frameworks in your iPhone projects.  There is no dynamic loading of libraries (which frameworks are) on the iPhone.  Instead, you end up copying all the files into your project.

In this example, we will create a folder named “UnitTestingFramework” in our project to separate it from the rest of our code.  If you’re using a lot of external code in your project, you could put this under another folder called “OpenSourceFrameworks.”  I’ve done this in most of my consulting projects, but we’ll keep it simple since we’re only working with one “framework” in this tutorial.

So: In Finder, create a new Folder inside your “example1” project folder called “UnitTestingFramework.”


Create a folder named UnitTestingFramework in the example1 project folder.
Create a folder named UnitTestingFramework in the example1 project folder.

Drag and drop the “UnitTestingFramework” folder from Finder into the “example1” project in Xcode.  When the sheet pops up, do not select “Copy items into destination group’s folder (if needed).”  The reason is because it already is in the “example1” folder.

You should see a Group called “UnitTestingFramework” underneath the “example1” Project.


You should see a UnitTestingFramework group underneath the example1 project.
You should see a UnitTestingFramework group underneath the example1 project.

Step 3: Find and Install a Unit Testing Framework

In the first post, I alluded to a group of “diligent and ingenious engineers”.  I was specifically referring to the Google Mac Team.  They’ve created a great project called Google Toolbox for Mac.  It actually does a lot more than unit testing.  For example, I used their Address Book interface to make working with Address Book on the iPhone much nicer.

In this tutorial, we’ll focus on one subset of Google Toolbox for Mac, the unit testing portion.  We won’t even use the entire unit testing portion, since there are helpers for Mac OS X unit testing as well.

First, you’ll need to download the source.  The latest stable version is their 1.5.1 from June of 2008.  You can get it from here:

You could also get the latest from Subversion, but we’ll focus on the stable version for this tutorial.

Unzip the file by double-clicking on it in Finder if it wasn’t unzipped already into a folder.  Then go into the folder and find the following 7 files:









The 7 files you need to select from Google Toolbox for Mac.
The 7 files you need to select from Google Toolbox for Mac.

Drag and drop those 7 selected files to the “UnitTestingFramework” group in Xcode.  When the sheet appears, make sure to check “Copy items into destination group’s folder (if needed.)”  This time, we need to copy them from the Google Toolbox for Mac download to our project and specifically to the UnitTestingFramework folder we created in Step 2.

You have all the raw ingredients now, but you will need to perform a few more steps to be able to find and run unit tests in your iPhone project.

Step 4: Create a “Tests” Target

Create a new target via Project > New Target.

Choose iPhone OS > Cocoa Touch > Application.

Call it “Tests”.

In the first post of this series, we discussed that there are only two types of Targets available for iPhone projects.  Applications are the only ones that can run and we want to execute our unit tests.  That is why we are adding this new “Tests” target.

We are almost there.  Now we just need to tell the “Tests” target to find and execute our unit tests.

Step 5: Add a Run Script Build Phase to the “Tests” Target

Select the “Tests” target.

Control-click (or right-click or whatever finger gestures you use on your fancy new MacBook Pro with no buttons) and select Add > New Build Phase > New Run Script Build Phase.

Enter “./UnitTestingFramework/” in the Script text area.  Note that if you had spaces in your folder, you would need to escape it with a backslash like “\ ” here.  So another lesson is to not include spaces in your folders to keep things simple.


Enter "./UnitTestingFramework/" in the Script text area.
Enter "./UnitTestingFramework/" in the Script text area.

What is this “”?

It is a shell script that the Google Mac team has created.  It sets up some environment variables to help with executing the unit tests.  The real magic will be explained later in this series.  Hint: it is in those files you selected and dragged into your project.

Step 6: Ensure All the “UnitTestingFramework” Files Are Part of the “Tests” Target

Select the “Tests” target in the Active Target portion of the Toolbar.  You can also select in via the menu item Project > Set Active Target > Tests.  Ensure tha the Active Build Configuration is Debug and the Active SDK is Simulator.

Select the UnitTestingFramework group.  Look at the list on the right side and make sure that all the *.m files are checked.  This ensures that they will be included in the Tests target.  Check any that are unchecked.

Note that you’ll want to make sure these are all unchecked in your “example1” target as well.  You don’t need these testing “framework” files in your regular application target.


Check all the UnitTestingFramework *.m files for the Tests target.
Check all the UnitTestingFramework *.m files for the Tests target.


Step 7: Run the Tests and Verify Success

At this point, the project is fully set up to run unit tests for an iPhone project.  To verify this, press the Build button on the toolbar or use the menu item Build > Build.

Open up the Build Results so you can see the progress.  You can use the menu item Build > Build Results.

To better see the progress, you will want to look at the detailed Build Transcript.  To see this, you’ll need to click on the little transcript icon in the Build Results window.


Click on the Build Transcript button to see the details of the unit tests progress.
Click on the Build Transcript button to see the details of the unit tests progress.

You should see: (give or take a few miliseconds)

“Executed 0 tests, with 0 failures (0 unexpected) in 0.004 (0.004) seconds”.

This is success!  Your project is set up correctly.  We have no tests yet.  We will cover that tomorrow.  But this shows that the unit testing “framework” is running correctly.  If we did have any tests, they would execute and show in the Build Details.

If you don’t see this, don’t worry – try reading part 4 of this series: Pitfalls That You May Encounter when Running iPhone Unit Tests and How to Overcome Them.  You can also visit the Google Toolbox for Mac Google Group for support via an email discussion list.

Note that the results were reported twice – this is a known bug in 1.5.1 and is fixed in a later version.

You can see the completed version of this project at  That’s sort of like when you see a chef pull out a fully cooked pie at the end of  cooking show.

If you have any questions about this tutorial, let me know in the comments.