If you’re an iOS programmer who only programs CocoaTouch, I want to encourage you to give desktop Cocoa a try. I’ve primarily been shipping iOS software for the last two years, but I’ve also been doing a fair amount of Cocoa programming on the desktop during that time, either writing helper tools or implementing parts of the iOS app on the desktop.

Program turnaround time is much faster on the desktop. You don’t have to wait for your code to load up on a device or for the simulator start up. You also don’t have to worry about “The simulator is already in use so I’m not gonna run your code right now” smackdowns from Xcode or your provisioning profiles have gone walkabout.

Drawing Models

The drawing models are the same on iOS and on the Mac, and the toolkit support classes are similar even if they’re spelled differently (UIColor and NSColor, UIBezierPath and NSBezierPath). If you’re drawing with CoreGraphics, much of the code is not only similar, it’s identical between the desktop and the device. I have a personal app that supports the desktop and device where all of the model code and all the drawing code is identical, with not an #if or #ifdef in sight. Platform specific code is used to make the containers that holds the drawing and for soliciting configuration information from the user using native UI controls.

Here’s a screen shot of the Class Builder app I built for Cycling Fusion. It has three striped gradient views. There’s one with the five different major settings, and two for the heart rate: zone low/mid/high and one for the five different heart zones. So there are three different slabby things on this screen. The actual drawing is kind of complicated – the different slabs are darker as they go down, but each one has its own gradient from lighter to darker.

The graphics designer delivered a photoshop file that we used that to generate different pngs for display. But we were moving things around during development and resizing them to get things Just Right as we iterated on the features. Regenerating six different graphics assets (the three you see here in regular and retina sizes) was unfun. I decided to implement it in Core Graphics (a.k.a. Quartz). That way it would draw at maximal resolution, as well as be a component easily reusable in other apps.

Luckily many Core Graphics drawing model features are similar to Photoshop which made implementation straight-forward. I used a Mac application do to the work:

I could iterate very quickly. Implement the rounded corners. Resize the window to make sure things looked good small and large. Then fill in the slabs. Run and resize the window to make sure things stayed sane when the slabs were made larger and smaller. Once I had everything looking how I wanted, it was a piece of cake to put the Quartz code into the iOS project.

Support Tools

Support tools are another place where desktop Cocoa comes in handy. You won’t ship these tools to customers, but you use them to create and edit things that the iOS app uses.

Another side project I have is a music dictionary geared towards musicians in a rehearsal who are wanting to look up terms quickly. Type in part of a term and it’ll filter the list to match what you type in:

I wrote a Mac application to edit the dictionary, which is populated (manually) by scouring markings in actual orchestral and band parts. I have tools to help me find duplicates in the data set, quickly attach tags for easier browsing, and generally massage things so that the app can load the database quickly:

Being comfortable with Cocoa and CocoaTouch lets me construct model objects, as well as drawing code that can be used in both worlds, making me a more awesomer developer.

Shameless Plugs

And, as you can probably guess, the Big Nerd Ranch can handle all of your Desktop Cocoa training needs! The definitive Cocoa programming book is now in its fourth edition, and we also have an Beginning Cocoa class coming up in August.