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.

Dan Benjamin has a great weblog, and has just taken the plunge into the world of recorded audio broadcasting. Checkout the Hivelogic Podcast (direct feed), whose first episode features a chat with John Gruber of Daring Fireball. The quality of the podcast is already much higher than most first episodes, so I’m looking forward to listening to the series evolve.

The content of the first episode is centered around the rumored Apple cell phone, with John taking the position (and more-or-less convincing Dan) that Apple can’t announce a completed product at Macworld, because the product simply requires too many cooks in the kitchen. He suggests that if and when Apple pulls together all the required resources to build a complete product, there will be so many companies involved that a leak is inevitable.

Maybe.

But I’ve learned to never underestimate Apple’s ability to redefine the rules. There’s just no saying what they could have cooking up their sleeve. And they have a huge, competent workforce that has been mostly slapped into confidential submission. So I’ve got a bold prediction about the mythological Apple Phone (and yes, this is a real prediction, unlike my last phone entry).

To be honest, I don’t know enough about mobile phone technology to be qualified to speculate, but here goes. I know that among the alleged problems for Apple are:

1. Apple has to make deals with wireless networks ahead of time.
2. Apple can’t realistically produce a device that supports multiple standards (e.g. CDMA and GSM).

So what’s my totally uneducated, shocking prediction for Macworld? Apple will get around these obstacles by redefining the mobile telephone market. Apple will modularize the “communication component” of mobile phones, by turning the hardware required for connecting to and communicating with any particular network a “snap-in” component: basically an extension of existing SIM cards. For existing SIM-card carriers, a module that adapts the SIM card to the necessary circuitry to communicate with a GSM network, and for other carriers, a module that handles the whole shebang. The whole thing will connect to the Apple Phone via a custom compartment underneath the battery. “Only Apple could have done this.”

You’ll buy one “iPhone,” and as many communications modules as you need for the various networks or vendors you do business with. As I understand it there are at least some vendors who will work with “unlocked” phones. That means roughly that the vendor will work with a “commmodity phone,” such as Apple could develop independently and secretly. But Apple doesn’t want to be limited to these commodity vendors, and they don’t want to confuse customers with a rash of different phones. So next week Apple will come out two mobile phone products:

1. The Apple Phone. Part iPod, part phone, part magic.
2. The Apple GSM Module. This will come bundled with the first Apple Phone as the only option, allowing the Apple phone to work with any vendor able to provide a GSM sim card.

At the Macworld keynote, Steve Jobs will hold up the world’s sexiest phone, which will glisten in the rapid-fire of flash photography as he announces instant availability for unlocked GSM networks. And one more thing: Apple is “anxious to work with any wireless network company that wants to develop an Apple Phone communications module for their customers. We’ve designed the a comprehensive hardware spec and we believe that most carriers should be able license and build these modules with a list price of $49.95USD, with a reasonable profit margin built-in.”

Game over.