Plug-ins the Cocoa way

For many graphics applications, plug-ins are a way of life. This essay presents a method that minimizes the amount of work required to support different host applications, or even different versions of the same host. I used these techniques in our IconBuilder plug-in for Photoshop. These instructions have already helped one fellow developer; with the help of Google, hopefully there will be more.

My goal was to use Cocoa and NIB files produced by Interface Builder for driving the plug-in user interface. As I began to work on this project, I also realized that it was possible make the user interface independent of the underlying binary file formats: a CFM shim can load a Mach-O bundle.

Here are the steps to accomplish the task:

  1. Photoshop loads the plug-in which is built with Carbon.
  2. The Carbon plug-in searches for a Cocoa bundle in the plug-in’s resources with CFBundleGetBundleWithIdentifier and then loads it with CFBundleCreate.
  3. Once the bundle is loaded, I get a function pointer to the Cocoa code to execute using CFBundleGetFunctionPointerForName.
  4. After I’m in the Cocoa code, I create my own NSAutoreleasePool and then call NSApplicationLoad(). At this point, you can work with controller objects to get things setup and call [NSApp run] to get a run loop going.
  5. From this point on, I can use all the Cocoa and Foundation frameworks. Interface Builder NIB files work fine, too.

I use the Carbon code base with both Codewarrior and Xcode to produce both the CFM and Mach-O versions of the shim.

The biggest advantage to this approach is that your user interface and processing code is independent of the glue code that passes data back and forth to the host application. You could, for example, easily adapt the “plug-in” part to work with Aperture’s new plug-in architecture and not have to worry about 99% of the rest of the code. We take this approach with our IconBuilder product: PS7 and CS3 have slightly different plug-in specifications, so we offer two plug-ins that use the same UI/processing bundle.

Another advantage to this approach is that you can do testing without having to run under the host application. I use a small test harness that loads the UI/processing bundle and feeds it data. This makes it much simpler to work in a debugger without the host application getting in the way. You could also use a similar technique to build a standalone application.

Finally, there’s much better documentation than when I figured all this stuff out. Here’s something at ADC that will help get you started.

Don’t feed the raccoons

Piracy is a fact of life for software developers. There are always douche-bags who think they should get your hard work for free. Sometimes this takes the form of distributing serial numbers, sometimes it’s kracking the application to eliminate the checks. I’ve come to accept this as part of running a software business.

Recently, however, a certain individual has made a claim that Twitterrific has a security vulnerability that allows it to be modified and not display ads. That is a very serious claim; not just for my application but for all Cocoa applications. And it puts my good name in a bad light.

I am not going to link to the individual in question since it’s likely that these claims are attempts to generate traffic (link baiting.) Instead, I’ll link to a salient tweet by my friend John Gruber.

Without getting too technical, the claim is that a tweet received by Twitterrific causes code to be executed. That code modifies the application and eliminates the ads. If true, this would mean that there is a security vulnerability in the Cocoa frameworks that process XML (NSXMLDocument) or text (NSString). A security vulnerability of this type would have broad implications: applications like Safari, NetNewsWire, and anything else that processes XML or text would be vulnerable to malicious payloads. A vulnerability of this magnitude should be reported directly to Apple, not just posted to some shitty little web log.

Fortunately, I have yet to see this exploit actually do anything. Nor has the person making this claim produced any source code showing how it’s done. (Why does a vulnerability have to be released under the GPL anyway?)

All I can assume at this point is that Marc Fiszman is not only a jackhole, but a very dangerous one: and not for the security exploit, but for the libel.

My partner, Dave Brasgalla, has a phrase for this kind of situation: “Don’t feed the raccoons.” Feeding these individuals only makes them want more food and leads to unnatural behavior, malnutrition and disease. So my best course of action at this point is to clear my name and ignore this jerk.

There is some good to come out of all of this: I’m reminded that for every idiot on the Internet, there are hundreds of individuals that are kind and supportive. The comments and registrations we’ve received in response to this incident are much appreciated. I thank you all.

Hacking quicker

It’s no secret that I’ve started hacking on my iPhone.

And what’s the most frequent thing I use in development? SSH2 to copy new builds onto the phone and view NSLog output from the shell.

And is it a pain to enter your password every frickin’ time? And is it slow to connect? Yes and HELL yes.

But we can make it better.

First, let’s make a public key that’s compatible with SSH2. Using the id_dsa.pub key generated by OpenSSH on Mac OS X, we’d use these commands:

% ssh-keygen -e -f id_dsa.pub > id_dsa_ssh2_aster.pub
% scp id_dsa_ssh2_aster.pub root@192.168.0.100:/var/root/.ssh2

(“aster” is the name of my development machine, where I’m logging into the iPhone from. The “192.168.0.100” is the IP address of the iPhone on my local network. You may need to create the /var/root/.ssh2 directory on the iPhone first.)

Now, on the iPhone, you need to create a file that tells the SSH2 daemon where to find the public key. In /var/root/.ssh2, create a file named “authorization” with the following contents:

key id_dsa_ssh2_aster.pub

If you login from multiple machines, you’d add a new “key” line for each reference to the public key.

That’s all you need to do to avoid the login prompts. We’re halfway there!

Now for the more annoying thing: delays at login. It’s not because the iPhone is doing something stupid like running Javascript: it’s trying to resolve the client host name. Since the iPhone isn’t running lookupd, that’s kinda hard to do, so all we’re really doing is waiting for a timeout :-(

The simple fix is to turn off the “ResolveClientHostName” feature in the SSH2 daemon. As long as we’re tweaking things, let’s also add “NoDelay” to improve TCP network performance. Open /etc/ssh2/sshd2_config on the iPhone and update the configuration to:

#       ResolveClientHostName           yes
	ResolveClientHostName           no
...
#       NoDelay                         no
        NoDelay                         yes

Now restart the iPhone and watch your blood pressure decline as you continue hacking.

Update: These instructions assume that you are using OpenSSH2, not Dropbear. Installing OpenSSH2 gives you a full suite of tools for communicating with the iPhone.

Does your app icon suck?

Yeah, I see a lot of icons in my business. I often get asked what makes for a successful desktop icon. And I’ve answered many times—but never in public. This essay also gives me a chance to write about something other than the iPhone :-)

Let me begin with this disclaimer: this discussion is directed at independent software (”indie”) developers. Our corporate clients, like Adobe, Apple and Microsoft, have very different needs and objectives when dealing with iconography for software suites. Please also remember that I’m a software developer by trade, not a designer (although, I’m not completely clueless when it comes to the arts.) This discussion will cover a lot of things designers already know—and things that developers need to know.

Before I talk about the specifics of icon design, it’s important to realize what your application icon represents. It’s your brand: it shows up in the Dock, on your download page, and in product reviews. People may remember your app icon more than they remember your product name. A strong icon design results in an equally strong brand.

What do you think of when I describe an icon that’s a truck sporting a yellow cab with a purple cargo?

That’s Transmit’s brand. It’s so good, other people want to use it.

Would you believe that people actually thank us for making that little truck icon? It’s true—an icon can have a huge impact on people’s perception of your product. If your app is a joy to look at in the Dock, people will be in the right frame of mind when launching the application.

This effect of good design is contagious, too. The Twitterrific icon is an example; the strength of the icon has carried over into other applications either directly or indirectly. People associate a blue bird with Twitter now—at the time we created the application, Twitter’s only brand was the word mark.

It’s also important for your design to be unique. The world doesn’t need another globe icon for a network application. Be careful about using the “document and tool on the desktop” metaphor; it may be recommended by the HIG, but it also means you’re playing on a field crowded with other similar designs.

Of course there is still room for creativity when working with familiar metaphors. If you look at Bryan Bell’s icon for NetNewsWire or Jon Hicks’ work for Firefox, you’ll see that the globe is a secondary element in the design. The complementary colors of the satellite and the fox are what draw your eye and make the image memorable.

One of the most unique icons to come around in a long time it the Coda icon. (I feel fine making that claim because I had no substantive involvement in its design—I’m just happy to have it in my Dock.)

There’s a interesting story that went along with this icon’s creation. This story illustrates how much thinking and rethinking goes into a successful design. It also shows that you shouldn’t work in a vacuum when dealing with something as important as defining your brand.

The early concepts for Coda’s app icon was a forklift; a natural extension to the Panic truck. But the release of a similar application that used this metaphor forced us to consider a new direction. In retrospect, that was one of the best things that happened in the project.

So without a forklift to work with, some more brainstorming ensued. Gedeon Maheux came up with the idea of using a leaf or seedling to represent the continual care and growth that a web application typically receives. Dave Brasgalla started developing this concept with a series of hand drawn sketches and simple vector artwork.

Coda concept artworkOriginal concept sketch for Coda

Cabel Sasser, who did the UI design for Coda, liked the concept sketch, but was hesitant about its use in their product. Ged convinced him it was a good idea because of its uniqueness.

Once we got the go ahead from Cabel, David Lanham started developing the icon. As with any design job, there were multiple revisions before everyone was happy. I first saw the icon toward its final revision (before the addition of trichomes and the rearrangement of water droplets.) Like Cabel, I had doubts about the icon’s simplicity.

Coda icon before final releaseCoda icon before its final release

The deciding factor was that it stood out on product website and in a list of other icons. Its simplicity and uniqueness was its greatest strength.

Comp of Coda icon on Panic websiteComposition showing how Coda icon would show up on Panic website

And the punchline for this story: a conversation with Cabel at this year’s WWDC revealed that he and Steven Frank originally had the idea of doing a leaf to represent their web studio application. But they discounted it and never mentioned it anyone. I guess that means that great minds really do think alike :-)

Note: There’s more that I’d like to show about this project, but I don’t want to steal any thunder from Cabel and his presentation at C4. Hopefully this post will whet your appetite as much as a link to Gina’s. It would also be safe to assume that this post will be updated sometime after our little get together in Chicago :-)

So what should you look for when developing your own application icon? It’s really pretty simple when you get down to it—the key elements are:

  • Color
  • Shape

When dealing with these elements, strive for simplicity and clarity. How the icon looks at 16×16 pixels is just as important as its representation at 512×512. Complexity in the larger sizes will not work well at the smaller sizes. A vibrant color that looks great at 16×16 might be overpowering at 512×512.

To get an idea of how these two elements are important, let’s do a little experiment. (Regular readers will find that I love doing “real world” tests to back up my statements.)

Open your Applications folder and set the list view to the smallest size (16×16.) Now scroll down through the list and pick out which icons jump out at you. Now ask yourself why—the answer is color and/or shape.

Here are the applications that caught my interest, their strongest design element, and some thoughts I have about each one:

Adium (color & shape)
A green duck makes a strong statement, although I think making the color a preference is taking customization a bit too far.

Firefox (color)
Circular icons tend to be overused, but the fox’s “C” shape overcomes this.

GarageBand (shape)
A unique shape that draws the attention of people who like music (like me.)

NetNewsWire (color)
The complementary colors in this icon are particularly strong and make for a very dynamic icon.

PhotoBooth (color)
Unique in that it successfully uses a gradient—ranges of color typically get lost in smaller sizes.

Skype (color & shape)
One of the few icons that incorporates the word mark clearly and successfully.

Parallels (color & shape)
I have no idea what the shape represents, but it’s unique and clearly represents the brand. Without the gold coloring, the shape would be reminiscent of the brand used by DC Shoes.

QuickTime (shape & color)
A clever icon that uses the letter “Q” to represent the brand. It’s been around a long time and still looks good—you can’t say that about most applications that were released in the early 1990’s.

Hopefully this essay has given you some basic insights on how to approach the design (or redesign) of your application’s icon. There’s no way that a fantastic icon can overcome crappy code, but something nice to look at will definitely affect people’s perception of your hard work. And be sure to give brand development as much care and thought as the lines of source code in your project: it’s not something that you just slap on your application before you ship.