The Treachery of NSImages

Incisor IconThanks to my recent bout of unemployment, I’ve finally been able to finish one of the projects I always said I’d do when I got free time. This one is to write a complete app for Mac OS X, from start to release.

The app is called Incisor, and it’s a lightweight image editor. I’m always finding pictures I want to use in blog posts on websites, or Flickr, or from my own iPhoto library. But getting them in a usable format means having to crop and resize them in Photoshop or iPhoto, both of which are overkill for doing something as simple as sizing an image.

It’s such a common task I’m surprised it isn’t being done already, but I haven’t found an app that works exactly like I want — in particular, being able to see a real-time preview of the edit, and being able to drag it directly into another program without saving it as an interim file. (Of course, now that I’ve put it on the internets, I’ll probably hear of a dozen programs that already do that. But what the hell; I wanted to learn how to write a Cocoa app anyway).

The thing about programming for Cocoa, at least from my limited experience, is that it’s crazy powerful, but it takes a lot of work to get your foot in the door. There are plenty of excellent tutorials out there, but they either start out too high for the beginner, assuming that you already know the basics; or they are so tailored to a specific task that you’re screwed if you try to do something different. I wrote the “Currency Converter” app about four times, each time ending up with a complete program but never understanding how all the pieces fit together.

I’ve read in more than one tutorial that the mantra of Cocoa programming is, “If it’s hard, you’re doing it the wrong way.” And it’s mostly true; the problem is finding out the right way to do it. Several times I would spend hours writing a bunch of functions to do something, only to have to delete it all once I discovered it was all covered automatically by one call to the system frameworks. For example, everything complicated about image manipulation is handled automatically by the Cocoa libraries — the effort in writing this app was half connecting the UI, and half digging through tutorials and documentation to find out what was covered and what I’d have to write myself.

And I’m just finding out now that at least half the UI code I’ve written could be scrapped if I’d used a different method. I guess I’ll know better next time.

I’m not sure if it’s just my experience, but developing something for OS X at the moment seems like a lot of super-powerful pieces without enough to tie them all together. It’s almost ludicrously easy to get a full-featured app out of the built-in frameworks and tools they give you for free; you can write a functioning web browser with just one line of code, for example.

Still, there’s not really anything guiding you through the process. For a while, after seeing how powerful InterfaceBuilder and Xcode are, and how deeply-integrated AppleScript is into everything, I was starting to think that development had gotten to the point where something like HyperCard wasn’t necessary anymore. But now, after finishing an app (albeit a very simple one) and looking back on where my time was spent, I’m convinced that the system really needs something that casual programmers and even non-programmers can use to get results not built into the stock iLife apps. Bring back HyperCard!

P.S. The app has some of the ugliest icons possible. If anyone wants to volunteer to make new ones, let me know.