Manually Adding a Swift Bridging Header

I watched the WWDC video, got excited, fired up my existing Objective-C project, added a Swift file, clicked “Yes” when Xcode helpfully offered to create a Bridging Header for me, and then watched helplessly as Xcode crashed. After crashing Xcode two or three times, I gave up, and added the bridging header myself, but how?

Here’s how:

1. Add a header file to your project, named [MyProjectName]-Bridging-Header.h. This will be the single header file where you import any Objective-C code you want your Swift code to have access to.

2. In your project build settings, find Swift Compiler – Code Generation, and next to Objective-C Bridging Header add the path to your bridging header file, from the project’s root folder. So it could by MyProject/MyProject-Bridging-Header.h or simply MyProject-Bridging-Header.h if the file lives in the project root folder.

You only need one Bridging Header. Add your #import statements to this file, and your classes will now be available in your Swift code without any extra import statements.


Book Review: Test-Driven iOS Development

Test-Driven iOS DevelopmentIt’s not often that I make spur of the moment book purchases, so when I do, it’s a pleasant surprise when they turn out to be gems. The book I purchased on a whim is “Test-Driven iOS Development” by Graham Lee, and it turned out to be one of those “right place, right time” purchases.

I’ve been trying to seriously adopt a test-driven approach to my development projects for a while, but it never really stuck. And though I’d read the standard books on the practice, I still couldn’t get past the seeming futility of it. I know I’m not alone. Most developers philosophize about the merits of test-driven development, but not as many actually implement it, and fewer still on the iOS platform.

It’s hard for me to gauge whether Graham Lee actually brings something new to the discussion, beyond the iOS details, but something clicked for me when I got through this book and then started implementing some of his techniques in my work. I currently work on a project where one group does server code, a developer might do UI code and another write the code that makes REST service calls. These tasks are often done independently and at different times, so I might need to write iOS code to make service calls long before the server folks have a chance to write their end. It’s in this environment that I realized how valuable a test-driven approach could be.

Anyway, back to the book.

The opening chapters begin with the basics of unit testing: what is it, how to write one, and tools you can use. Xcode offers OCUnit, and that forms the basis of most of the book’s code, but the author also mentions other tools that can make your life easier.

The meaty part of the book begins in chapter 5, as an example app is described. The detailed test-driven development gets going from chapter 6 through 9, in which the author steps through every step of the process from data models, app logic and finally UIViewControllers. What I really loved about this book was the lack of magic “hand-waving”. He doesn’t do something really basic and leave you stranded when you actually try a real world task. Every part of the app is developed in the book and many of the gotcha moments are described and solved as the book progresses. Chapter 10 wraps up the project, filling in some missing spots, and then the final chapters address related issues like applying TDD to legacy code, and cutting edge techniques like Behaviour-Driven Development.

I was excited to see some of the advanced techniques Graham Lee offers in this book for testing objects. He explains how to use method swizzling in Objective-C to swap in your own implementations for existing behaviour, and using associative references to add bits of information to objects to assist in verification. I’ve used these techniques to write some cool unit test code now.

Aside from the technical knowledge I learned from this book, the biggest take-away for me was a shift in my concept of why I should be writing TDD code. It’s not just to test and verify code works. That’s important, but your unit tests also describe how your code should behave. This becomes important when you pass your isolated set of classes to another developer to use. Your unit-tests become a gold mine of information on how to use the code you just wrote.

I highly recommend Test-Driven iOS Development to all iOS developers. It will make you a better person.

Book Review: iOS SDK Development

iOS SDK DevelopmentI recently got my hands on a review copy of the new book, “iOS SDK Development”, by Chris Adamson and Bill Dudney. The book was just published at the end of November 2012, and it’s chock full of the latest techniques and technologies in Xcode and Objective-C.

The book is appropriate for developers who are new to the iOS platform, though the breakneck pace may be overwhelming. I wouldn’t recommend it for anyone brand new to software development in general. So if you’re an experienced developer and want to add iOS development to your toolbox, this is a great place to start. But it is not a “Learn to program” book.

As an experienced iOS developer, I was impressed by how current many of the concepts in this book were. Of course, they cover the basics like Table Views and hooking up UI elements, but they also introduce and demonstrate a lot of the newer SDK and language features too. They build interfaces with Storyboard and Auto-Layout. They use UIDocument and iCloud to store data. Also covered is the new Automation capabilities of the Instruments tool, which can enable you to run automated user interface tests on your apps. This is definitely an iOS 6 book.

Something I really appreciated was that the authors explained what could go wrong in many situations. They explained how things could break, and especially how to fix them. This is sorely missing from most development books.

The authors also walk you through the entire development cycle and offer informative chapters on testing and deploying your apps, including a mention of Provisioning Profile hell.

“iOS SDK Development” manages to cover a lot of territory in less than 300 pages, and by necessity they only offer a taste of some SDK features, like iCloud, and pass over others completely, like Core Data. I learned a few new tricks from this book and I’m glad I read it. I’d recommend it especially to developers who are new to the iOS world, but even veterans could learn a thing or two from this one.

Adding Array Subscripting To Your Classes in Objective-C

Xcode 4.4 added some great new literals syntax for collection classes and numbers, so now you can write NSArray *array = [@”one”, @”two”, @”three”]; And you can access those elements with array-style subscripting like this NSString *s = array[1];

On it own, that’s great, but there’s more under the surface here. When you write array[1], the compiler translates that into a method call named objectAtIndexSubscript:, which is implemented by NSArray. The cool part is that you can implement this method in your own classes, and then use subscripting on instances of your classes. You can also implement the sister method: setObject:atIndexedSubscript: to set values.

The code below is a simple example of how you could use this:

// Header

@interface ItemCollection : NSObject

@property (strong) NSMutableArray *list;

// Suport for Array-style subscripting. Ex. items[4] = @”hello”;

– (void)setObject:(id)anObject atIndexedSubscript:(NSUInteger)idx;

– (id)objectAtIndexedSubscript:(NSUInteger)idx;


// Implementation

@implementation ItemCollection

– (void)setObject:(id)anObject atIndexedSubscript:(NSUInteger)idx {

self.list[idx] = anObject;


– (id)objectAtIndexedSubscript:(NSUInteger)idx {

return self.list[idx];



// Using the class

ItemCollection *items = [ItemCollection new];

items[1] = @”boo”;

This is a contrived example, but with some imagination, you could find some cool uses for this to make your code more concise. Not only is this available for arrays, but you can use the key-value methods used by NSDictionary as well – objectForKeyedSubscript: and setObjectForKeyedSubscript:

You can read more about this here:

How To Make Great App Videos

With over 700,000 apps in the Apple App Store alone, the mobile app market has become incredibly competitive. So the success of your app in this environment has as much to do with marketing as it does with building a great app. One of the best tools you can use to market your app is a great app video. For most apps, a few screenshots don’t really convey just how cool your app is; not the way a video can.

The problem is, if you’ve ever attempted to make an app video, you’ll discover it can quickly turn into something sad. You need someone with real camera and editing skills to produce a video of your app running on an actual device. And taking a screen recording looks like, well, like you took a screen recording. So today I’m going to summarize a process that I’ve come up with to make slick, polished app videos that you won’t be embarrassed to post on your app web site. I’ll talk about some tools to record and edit your videos and then discuss exporting and publishing your videos.

Here is an example of a video I made to demonstrate the basics of the Coachable Soccer iPad app:

Screen Recording

To record the screen without making it look like we recorded the screen, we need to accomplish a few goals:

  1. We need to record the screen (obviously)
  2. We want to see the device hardware in the video
  3. We don’t want to see the mouse cursor. Rather we want to see some “touch” pointer instead.
  4. We don’t want our desktop in the video. A solid background would be nice.

Recording the screen would be easy if we used Quicktime Player 10. It allows you to record a portion of the screen and makes nice videos, but sadly your cursor will always appear in the videos. If Apple added that one feature, our lives would be so much easier. Instead, we turn to third party screen recording software. There are several out there.


 I settled on Screenflick [] which sells for $30. You can try it for free first, and live with a giant watermark on your videos until you decide to commit.Screenflick is solid screen recording software with a simple interface and some cool features. Foremost is the ability to remove the cursor from your videos. It also has the ability to overlay an image during all or a portion of the video and some keyboard stroke display options for your video output.

The next problem to solve is displaying the device hardware in our video. The iOS Simulator only displays decent hardware chrome for the old iPhone, which might be okay for you, but you’re not getting the best resolution possible and you’re out of luck if you want to demo an iPad app. The Retina Display iPhone hardware option does have a bezel but it looks nothing like the real device.


Here is SimFinger running with a retina display iPhone simulator. It’s the right idea, but doesn’t fit.

One way to solve this problem is with an application called SimFinger. This is an open source application living on github that has been neglected for the past couple years. It’s a cool concept that could use some spiffing up and updating. To get it, you’ll have to download the source code from the project on github: There are a bunch of projects bundled in there but the one you want is called FakeFinger. The idea is you run the simulator, then you run FakeFinger and it displays a device overlay (with a hole in the middle) on your screen directly over the simulator window. It also provides a slick white touch pointer for that extra jazz. The problem with it is that its images and hard-coded screen resolutions are outdated and don’t work with all the new iPhone and iPad simulator sizes. If you’re handy with Objective-C (and you should be if you wrote such a great app) you can hack the project code yourself and figure out what resolutions are appropriate for your task. You might have to do some image hacking too. I did to get an iPad overlay that was the right size for my screen.

You also have the option to turn the touch pointer on or off. You’ll probably want it on, unless you’re using another application to provide a custom pointer.


Another app I came across in my research was PinPoint []. Again, there are several apps out there to customize your mouse pointer, but this is the one I settled on. It has a bunch of great built-in customizable pointers, as well as the option to import your own designs into the application. It also has a nice key stroke display option which would be great for doing desktop application demo videos. This app is only $5 from the App Store.

I used PinPoint in some of my videos because I wanted a non-white touch pointer that would appear more clearly on a light-colored app background.

Create the Screen Recording

Once you have SimFinger running the way you want it to, and you’ve sorted out the touch pointer, you are ready to record a screen video with Screenflick.

The process is simple. Click ‘Start Recording’ and choose the area you want to record. I suggest choosing a sane aspect ratio like 4:3 to make your life easier. If it’s going to stretch beyond the limits of the SimFinger overlay, just make your desktop background white. When you’re done, press Cmd-Shft-2 to stop the recording.

In Screenflick’s Movie tab, you can add options to your video, like removing the cursor and adding a image like an icon to the video.

The best option for video export is to Export to Quicktime H.264. This is what seems to work best with Apple applications like iMovie.

Movie Editing with iMovie

Now you have a raw screen recording of your app. Don’t stop there. Get the latest version of iMovie for $15 and give your video a professional touch. iMovie is powerful, but it’s still a consumer grade product. It’s meant for making quaint home videos of your European vacation, so it’s lacking what seem like obvious features, like support for aspect ratios beyond 4:3 and 16:9. This makes it tough to use iMovie to edit anything non-standard that you want to embed on your web site. If that’s what you want, you need to shell out $300 for Final Cut Pro…and then learn how to use it.

In iMovie, we import raw videos and sort them into “Events”. Try creating an event for each app. Then you create a new project and drag-n-drop chunks of video from your events. Be careful when importing videos into iMovie when it offers to optimize your videos. My first attempt ended with a video at 1/4 the original resolution once I was done exporting it. Just import the raw full resolution video.

I won’t go into detail about how to use iMovie. It’s relatively intuitive to use. You can slice your video project into chunks. You can drag in various effects like text titles to precede a video chunk, or to overlay a video chunk. You can also drag your own images into these text titles. It doesn’t take long to get some slick looking effects going.

iMovie Interface

You can also add music to your video project. You can trim the music chunks, adjust the volume, change the fading of the clip, and many other cool features. You can import directly from your iTunes collection or from Garageband. To be clear, be wary of using copyrighted music in your app videos, especially if you’re planning to post them on YouTube. I managed to use Garageband loops to create the background music for my videos. If you’re more talented, you can use Garageband to create more sophisticated compositions. Royalty free music is another option; an option that isn’t always free…just royalty-free. There’s a difference.

Exporting Video

When your masterpiece is complete, it’s time to export it to a video format we can use in YouTube or an HTML 5 web site. If you want to upload to YouTube, choose Export Using Quicktime from the iMovie Share Menu. This should get you the best video to upload. You can find full specs and explanations here:

For video to embed in your site, I prefer Share Movie -> Export Movie and export to the biggest .m4v mp4 you can.

Converting Video

Miro Video Converter – It’s so easy to use. And it’s free!

If you’re posting your video directly on your site, you’ll need more than one video format. Sadly browser makers can’t agree on a video format. Firefox doesn’t support H.264, but only webm or ogg theora. I think H.264 is supported by all the other major browsers, even IE 9.

The tool to convert your video is the free Miro Video Converter. [] This program is a jewel! I wish all apps were this easy to use. Simply drag your video file into the Miro window, choose an export format and click “Convert”.

HTML 5 Video

In theory, HTML 5 makes video a breeze. No need for flash. Simple tags. Fully featured video player embedded in the browser. But of course it’s not.

We already learned that the browsers support different formats so you’re going to need two versions of each video. Once we have that, the video tag is pretty simple:

<video controls width=”405″ height=”540″>
<source src=”./video/MyVideo.webm” type=’video/webm”>
<source src=”./video/MyVideo.m4v” type=”video/mp4″>
<img src=”./images/MyAppScreenshot.png”>
Make sure your html document has the magic HTML 5 doc type tag: <!DOCTYPE HTML> at the top of the page. Without this, some browsers (IE9, *cough, cough*) won’t realize how to use the video tag. The final gotcha is to put a file called .htaccess in the folder with your videos. It should look something like this:

AddType video/ogg .ogv
AddType video/mp4 .mp4
AddType video/m4v .m4v
AddType video/webm .webm
AddType video/x-m4v .m4v

This tells the browser that the file format ending in mp4 is of the mime type video/mp4, and so on… This is the kind of stuff that wrecks the fun of web development for me, but that’s another article…


And that’s it. There are a lot of steps involved in making a great app video, which is why I wanted to put it all in one place. I spent a lot of time on Stack Overflow and various support forums over the course of a couple days trying to get this all figured out. Hopefully an article like this will make it easier for others…and for me when I forget it all ten months from now.

Book Review: Programming iOS 4 by Matt Neuberg

There are two approaches to learning the ins and outs of writing iOS apps. One can trudge through Apple Documentation, which consists of class documents and guides to the numerous frameworks and concepts that underlythe platform, or one can find a kick-ass book that walks through the process in a logical order and holds your hand all the way. If you’re lucky, you can do both, using the book as your base, your safe harbour, and then delving into the documentation on an as-needed basis. There’s nothing wrong with the Apple Documentation. In fact, it’s really good, and I couldn’t imagine writing iOS apps without it. But it’s still nice to have someone to offer you wise advice and occasionally wipe the tears of frustration from your face. That’s where Matt Neuburg comes in. More specifically, that’s where Neuburg’s tome, Programming iOS 4, enters the story. Published in June 2011, it’s one of the newest and most complete introductions to the iOS platform on the shelves.

If you want your hand held, but you don’t want to be treated like a child, this is your book. Programming iOS 4 starts right at the beginning, with the C language, which forms the basis for Objective-C. From there, he gently introduces (or reviews) some object-oriented programming topics before moving into the details of the Objective-C language. I am impressed with his approach and organization in chapters 4 and 5, in which he discusses separately Classes and Instances. In my experience, this is a novel approach to explaining Classes in the language, and I found it incredibly clear and helpful.

From there, he tackles the IDE: XCode. The standout chapter in this part of the book is Chapter 7: Nib Management, in which Neuburg not only describes the Nib loading process, but takes the reader into the guts of the process and attempts to reveal the dark sorcery that goes on behind the scenes. The standard approach is to simply describe how to connect outlets to code and ask the reader to accept the opaque nature of the underlying process. The rational for glossing over the details is to get the reader into building a useful project quickly before their interest wanes. Neuburg instead takes a more principled approach and works to build a strong base of understanding before launching into the “fun stuff”.

This approach follows consistently through the rest of the book, and if I have any complaints, it comes from this strategy. We are at page 125 before we learn about Nibs, and we are shielded from the evils of memory management until Chapter 12 (page 249). We are guided through Cocoa classes, events, memory management, accessors. Then views, custom drawing, layers, animation and touch handling. And only then, after we have all those building blocks in place, are we introduced to View Controllers, which form the foundation of nearly all non-game iOS apps. Chapter 19: View Controllers starts on page 435, which if I were an eager, would-be iOS developer, would require an heroic demonstration of patience and perseverance to wait for. Every Cocoa Touch app XCode template uses a View Controller as the basis of the app’s architecture, and having to trudge through 400 pages to get to this “good stuff” seems like a lot to ask. I’m not suggesting this is the wrong approach. On the contrary, I think it’s a brilliant way of building a solid foundation in the framework before getting to the magic classes that give us so much for free. It simply asks a lot of the reader and hopeful iOS developer.

Weighing in at over 800 pages and being so well-organized and thorough, Programming iOS 4 represents the best on offer, both for introductions to the platform and as a reference guide to nearly every basic component in the app development process. As you can imagine, it took a long time to put this book together, and Neuburg admits in the text that when he began writing, iOS was at version 3.1. A lot changed in that time, and the author studiously followed along and ensured the latest features of iOS 4 and especially of XCode 4 were included in the book. A side effect however, is that some chapters feel like they have unnecessary code examples that demonstrate the “old way” of performing some tasks, when simply showing the “new way” would have sufficed.

On the whole, I am extremely impressed with this book and I will be recommending it to my students in the iOS courses I teach. My complaints are minor, and I only include them here for completeness and in order to have something more to write than simply expressing how great the book is. The tragedy is that despite how new and complete this book is, portions of it are bound to be obsolete within a few short months when iOS 5 ships. We can only hope that Neuburg will once again be there to update his oeuvre and guide us into the brave new world of Automatic Reference Counting, iCloud, and all the other curves Apple decides to through our way this fall.

Book Review: The Art of Agile Development by James Shore & Shane Warden

I often browse the public library computer shelves just in case I spot a hidden gem, and mostly I find “Create Your Own Web Page!” or “Secrets of Windows 98”. But the gems are there, and I keep finding them, so I keep looking. A few weeks ago, I stumbled on The Art of Agile Development by James Shore and Shane Warden. I’ve recently worked in a group trying to follow Agile practices, and I’m desperate to find ways to improve my own “agility” when creating my own projects, so I was drawn to the book.

Agile development is not a specific practice or process in itself, but more of an idea for how software development should proceed. Its seed is the The Agile Manifesto, signed by many of the giants of modern software development way back in 2001, and many processes and practices fall under its umbrella. The company I recently worked for practiced Scrum. In this book, the focus is on Extreme Programming. So the title is a little misleading, but then again, I likely would have passed over it had it been called The Art of Extreme Programming. Like many, I’m sure, I have been instantly turned off by the idea of pair programming, and in my head XP == Pair Programming, and that was the end of the story.

So I’ll chalk it up to good fortune that I did pick up the book, and somehow managed to find the time to read it from cover to cover.

The Art of Agile Development is essentially a textbook for successfully implementing Extreme Programming for your software project. It steps through each element of the system, provides alternatives, and emphasizes in no uncertain terms that you may not pick and choose practices to create some Frankenstein monster of Agile Development and expect it to work. Each practice supports and reinforces the others. The meat of the book is in Part 2: Practicing XP, whose chapters are Thinking, Collaborating, Releasing, Planning and Developing. These chapters are specific and detailed, and even offer Mini-Etudes to get you and your team into the mood.

I have to admit that by the end of the book, I’ve become a convert to Extreme Programming. In the pages of this book, I saw some answers to many of the issues that have frustrated me in my team-work. I have a new perspective on pair programming, and I think I could get over my “don’t look over my shoulder” issues long enough to give it a fair shake. Now, as a solo-developer, it’s impossible for me to implement most of the practices (dual-personality pair programming?), but I now feel I have a solid understanding of the process and would be perfectly willing to sign on to a team that followed this branch of Agile Development. Notwithstanding the warning about picking and choosing elements, I also plan to implement as many of these ideas as I reasonably can in my own work.

Unless you’ve actually practiced Extreme Programming, or you’ve already read enough about it to have a firm grasp on the concepts, I recommend reading The Art of Agile Development before you make any judgements or succumb to prejudiced preconceptions of thorny issues like pair programming or open “bullpen” workspaces and dismiss XP as a hokey religion.

P.S. It looks like most of the book’s text is now available online at the book’s web site: