February 2008

There was this gift shop at Disney World with a whole bunch of monkeys and hats—and a couple lemurs.

I recently had the enviable pleasure of taking apart an old bubbly iMac and destroying the hard drive.

I noted that iPhone 1.1.4 firmware is out today.

And I wondered, what if it actually changed nothing? (Nothing other than the version string.) The change notes would just say something like, “Bug fixes and performance enhancements.”

Not that I think for one second Apple would do something like that. I’m just imagining. (Seriously. I’m not being sarcastic.)

My theory is that people would claim on their weblogs that 1.1.4 screamed compared to 1.1.3.

People would write things like, “I don’t know what they did, but my Safari rendering times have been cut like in half!” and “They’ve really got their IMAP implementation nailed, finally!” and “They must have cleaned up a lot of code, because everything feels so nice and smooth now!”

I bet every software developer has seen this—release a new version, even one you know to be slower, and some people will thank you for the performance boost.

It’s an urban legend that Fidel Castro tried out for an American baseball team. Apparently he wasn’t that good at baseball.

I figured it would be worth noting how I managed full and Lite versions of the same app, for the benefit of any Cocoa programmers considering the same thing.

It’s pretty simple, actually.

1. I had a separate target (named NetNewsWire Lite) inside the same project. (The easiest way to get started is probably to duplicate your existing target.)

2. In the Xcode toolbar I made sure the Active Target popup was visible. (So I could switch between targets easily.)

3. In the Groups & Files list, I enabled the Target Membership column, so I could set which files were included in which targets. (Ctrl-click, or right-click, on the Groups & Files header.)

4. Each target had a separate Prefix Header setting. (proprefix.h and liteprefix.h)

5. Instead of just defining #LITE in the prefix header, I did separate #defines per feature. (Not for every feature, but for features that may not appear in the Lite version.)

For instance, proprefix.h has lines like this:

#define FIND 1
#define COLUMN_DATE 1
#define COLUMN_SUBJECT 1
etc.

While liteprefix.h has lines like this:

#define FIND 0
#define COLUMN_DATE 1
#define COLUMN_SUBJECT 0
etc.

Then, in the right places in the code, I used those.

#if FIND
    [do findy things here]
#endif

The reason to do this on a per-feature basis is because it makes it easy to change your mind. For instance, one day I decided that the Lite version should get a date column, and I just edited liteprefix.h and rebuilt.

Easy? Yep.

Update: I bet I got the per-feature-#defines from working on Frontier.