It’s easy to beat up on Interface Builder, which until 10.5 ships, still feels a little crufty. It’s lagged behind Xcode in the major overhaul department. But sometimes I discover features that suprise me, like this tidbit from Apple’s Technical Q&A:

Q&A 1323: Interface element identification in Interface Builder

(Link compliments of Justin Anderson)

What the Q&A describes is a way to quickly identify the UI corresponding with any UI instance in IB’s hierarchical instance view. Just hold down control-shift and click an item:

Before learning of this feature, I’d just double-click items in the list to see where they were. A clunkier and less precise mechanism for browsing the whole nib quickly. Note: I had trouble getting this to work, but it seemed to me that if I just tried a few times it “cleaned out IB’s pipes” or something. Or maybe I was just doing it wrong at first.

Combined with Scott Stevenson’s recent bindings visualization discoveries, there seem to be a heap of features that I simply haven’t noticed. I guess I better keep my mouth shut before lambasting it too hard… nah!

First of all, if you’re dealing with any sensitive information on behalf of the user, you’re ethically responsible for storing that information securely. Mac OS X’s deeply integrated Keychain Services leaves you with no excuse for saving passwords, credit card numbers, or other sensitive information in plain-text format on the user’s disk. Access to items in the keychain is controlled by users, and when any new application asks for access, the user generally has to approve it:

I recently added Keychain Support to an application where the sensitive password information needs to be fetched at launch-time, every time it launches. That’s fine, but one of the important security features of Keychain Services is its ability to detect changed copies of a previously permitted application. This is to ward off abuses in case a hacker has replaced some trusted application with one that is programmed to siphon off your keychain passwords or something:

Usually this dialog appears only once in a while, after updating an application to a newer version, or installing an Apple software update. But when you consider the product development cycle: develop -> build -> test, you can imagine how frequently an application under development will trigger this warning.

Until provoked by this nuisance, I didn’t know about a feature in Keychain Access that allows users to open up access to a particular key. In general this would be a pretty insecure choice, but it makes a lot of sense for development purposes:

You’ll find the option in the “Access Control” tab after double-clicking any keychain item. So for the purposes of development, test against a key that doesn’t actually have any sensitive information in it, and set the access to unrestricted. Now you can rebuild and test as often as you like without being pestered by Keychain Services.

Mike Zornek wrote a great summary of his experience so far as an indie Mac software vendor. Billable is a slick time-tracking and invoice-generating application. The graph plotting “interest” (number of downloads) is especially illuminating since it shows how quickly the buzz of internet linking can dwindle away. Depressing, innit?

He’s about to release Billable 1.1, which he points out has taken longer than he expected. I’m jealous, because I’m also quite late in getting my 1.2 release of FlexTime out the door. Hopefully it will be ready before the month is up!

If you use iTunes to manage your podcast subscriptions, and you have enough of them, it can become quite difficult to sift through the list to see what has been recently updated. I often find myself wanting to quickly check whether anything new has arrived in say, the past day or two.

My Recent Podcasts script makes this a breeze:

If any podcasts are found, they’ll be presented in a list, where you can choose one to automatically start listening to it (though I personally rarely listen in iTunes itself):

Note there is a user-customizable flag in the script itself: kIgnoreAlreadyPlayedPodcasts, set to false by default. But if you would like to limit the listing to items that you haven’t already listened to, just set this flag to true.

Best part is that all of these dialogs are keyboard-navigable. So I popped the script into my iTunes script folder, and gave it an application-specific shortcut Cmd-Opt-R (with FastScripts, naturally).

Enjoy!

Update January 8: It’s been pointing out in the comments that Smart Playlists might be a better solution for this kind of scenario. I tend to agree, but I’m leaving the script and entry up here in case people find this preferable, or if they just want an example of the scripting techniques.

See Peter Hosey’s example of how you might accomplish the same thing with a Smart Playlist.

Note that the workflows he demonstrates could be even simpler by using the “Podcast – is – true” rule. He reminds me that smart playlists can be nested, which is just really, really cool.