Safe Casting in Objective-C

I’m writing a small safe casting for Objective-C. I’ll be putting it on GitHub

The Story

Somewhere on the web, there was some test I took to determine how well I know Objective-C. I think it was elance. One question which infuriated me at the time was something like “if you have an array NSArray *a, how do you make it an NSMutableArray?” The reason I got angry was that the answer was supposedly

NSMutableArray *mutableArray = (NSMutableArray *)a;

Except that this is tremendously dangerous, wrong, stupid, crazy… well. You get the picture. The real answer of course is something like

NSMutableArray *mutableArray = [a mutableCopy];

Unless you want to actually modify the same instance that a is if it’s a mutable array, in which case you have to do the all-too-familiar dance

NSMutableArray *mutableArray;
if ([a isKindOfClass:[NSMutableArray class]]) {
    mutableArray = a;

At which point you proceed to mutate mutableArray, which is also a, possibly ignoring the fact that mutableArray may be nil. Or maybe you return early if it’s nil.

Casting is Dangerous

If you cast between object that are the same foundational type, no work is done. What I mean is that if you cast from ...


I’ve written Objective-C code to turn a service response into a fully hydrated model object too many times. It also seems I’m not the only one. Just a couple of weeks ago, I decided to put together OHMKit so I’d never have to write boilerplate code for object mapping again.

Check out the source on GitHub!

OHMKit is a mixin to make any Objective-C class easier to hydrate from a dictionary representation, such as you might get from a web service. It makes it easy to keep any direct knowledge of the idiosyncrasies of the service you’re consuming tucked away in a single place.

It exists because RestKit (which is awesome by the way), is sometimes too big, heavy, and indirect.

This project doesn’t know about networks. Use AFNetworking.

This project doesn’t know about routes. Use SOCKit.

This project doesn’t know about CoreData. It will not manage graphs of entities for you quite like RestKit does. But it is built on KVO, and does not care about your model objects’ super class. So you can safely make subclasses of NSManagedObject mappable.


Basic Mapping

Given a model

@interface MYModel : NSObject
@property (nonatomic, strong ...

Per File ARC in CocoaPods

tl;dr do |s| = 'MyPod'
  non_arc_files = 'Classes/FirstNonARCClass.m',
  s.requires_arc = true
  s.source_files = 'Classes/*.{h,m}'
  s.exclude_files = non_arc_files
  s.subspec 'no-arc' do |sna|
    sna.requires_arc = false
    sna.source_files = non_arc_files


Automatic reference counting (ARC) is a good thing. It's a great compile-time technology that makes it easier, in most cases, to not accidentally introduce trivial memory leaks in modern Objective-C apps.

But sometimes, you have older code with traditional memory management; it's not really worth converting to ARC if it's correct, and possibly finely tuned. And sometimes ARC introduces a little unnecessary overhead that can balloon out of control when handling large numbers of objects. There are also good reasons to put Objective-C objects into structs or other odd places that ARC prohibits or makes difficult (Objective-C++ anyone?).

That said, ARC is almost always a good idea. And so disabling ARC should be the exception, not the rule.


CocoaPods is an excellent dependency management system for Objective-C projects. Dependencies are distributed as 'Pods' which are described in podpecs. A podspec is a kind of build description, that specifies where the source ...

CocoaPods and GYP


CocoaPods is an excellent dependency management system for Objective-C projects. Dependencies are distributed as 'Pods’ which are almost exactly like gems. A podspec is a kind of build description, that specifies where the source is to be found, dependencies it has, and how it should be configured and compiled. The best part is that they’re extremely legible.

This is a great improvement over the typical git submodule, or linked Xcode project for each dependency. To use CocoaPods, you specify your application’s dependencies in a Podfile. This is typically a concise list of the pods required to build the application. CocoaPods generates a Pods project with a single target consisting of a single static library custom-built for your app to contain all the dependencies in one place. The Pods project that gets put into a workspace along with your project, so that everything plays nice with Xcode as both and IDE and as a build system. The Pods project doesn’t get checked in to your repository because it can be completely regenerated from your Podfile.

CocoaPods turns out to be a partial build system that takes some of the bite out of Xcode. With respect to dependencies ...


I just published a new app, Swirltastic, in the iOS app store. Swirltastic is both a toy and an art project. It’s a big mess of colorful swirls that respond to your touches.

My hope is to continue releasing updates that introduce new and interesting ways of interacting with the swirls.

Deleting Folders in TrustyBook

tldr; Try swiping across the folder in the list view. Or see the button in the next update.

It seems the most frequent confusion people have when using TrustyBook is how to delete folders. I’ve gotten a number of bad reviews because people think it can’t be done. The feature’s been in TrustyBook since I implemented folders, which was so long ago I don’t remember if it was after the first release, or when I was playing around with the original code on a train between Portland and Seattle, months before the world saw TrustyBook.

The general confusion this seems to have caused is really highlighted in John Gruber’s frequent likening of gestures to keyboard shortcuts (regarding the home button, close buttons). If a feature is only accessible via a gesture, even if it’s a standardized gesture, it’s effective hidden. It’s interesting to think that all the people who didn’t know how to delete folders in TrustyBook likely don’t know about the widely-used swipe to delete gesture across all iOS apps.

I made a video demonstrating the swipe gesture in TrustyBook and put it on the app’s support page ...

iPhone Color Picker gets a little love

Back in August I put out an open source color picker for the iPhone. Announced here. It hasn’t recieved much attention in the way of people writing about it, but it has been downloaded over 600 times!

A couple of weeks ago I gave the project a little more love. The UI’s been polished, some internal code cleaned up, documentation improved, and wiki populated. Next on the docket is a truly polished version for iPad modal views.

One day soon I’ll push out an updated version of TrustyBook with the improved color-picker code.

iphone color picker screenshot

iPhone Color Picker


This code now lives as iOS Color Picker on GitHub and is vastly improved. There is an example project showing how to use the color picker, also on GitHub.

Between two conferences, ASIC in Bend and CogSci in Portland, I’ve taken a brief detour into Seattle. In addition to walking around the city and putting the finishing touches on my talk for CogSci (here’s the corresponding paper) I took it upon myself to make a super-simple iPhone app in the shortest amount of time possible. Without a lot of starting experience in iPhone development, it turns out that it took me about two days of mostly not working on it. But this post isn’t about that app; I’ll write about that in the near future when the app’s submitted to the appstore and I have some time to craft some “Marketspeak”. This post is about my adventures in crafting a color-picker for the iPhone.

Apple wasn’t kind enough to include a system color-picker in iOS. And given the iPhone’s general bend against productivity that’s only fitting. Googling for iPhone color-picker code returns a bunch of options that amount to a few ...

On Paginated Text

The New York Times has a short piece on the much-discussed Microsoft patent application for simulated page turns on a touchscreen device. I’d already seen the patent, and find it generally troubling that something so simple, easy to implement, but above all obvious, may find its way into anyone’s patent portfolio.

But the NYT piece pointed me in a direction that hadn’t caught my attention in the past couple of days. The focus turned to whether page turning is at all appropriate in a digital medium. Nick Bilton, the author of the NYT bit clearly expresses his preference for scrolling, and for good reason and backed with some experience. He writes that across a page flip, the reader’s eyes have to adjust to the new page, whereas in scrolling text the page adjusts to the reader. He also cites various other people’s perspectives in favor of scrolling, mostly focused on calling page flipping anachronistic. There was only one ill-represented voice from the opposing camp, the Design Dare blog.

What design dare mostly writes in that post is that if done right, page flips are preferable to scrolling, and additionally describes how to do page flips ...