{13bold}'s State of the Apps Address

Matt Patenaude

This silence has gone on too long. It's not you, it's me… it's just something I'm uncomfortable talking about. I don't like people getting inside my head, it scares me. But you're important to me, and if we're going to make this relationship work, I need to learn to open up more.

It is without further ado that I present to you our first ever "State of the Apps" address! :)

Before We Get Started

Before we launch headlong into a status update, I would like to clarify briefly: I've been somewhat busy lately. My schedule is significantly lighter than it was last year at this time, so believe me, I'll find time to work on all of this stuff, but as of late I've just been a little bit swamped. Fear not, development should pick up quickly relatively soon.


Bluebird's development is going well — it's currently living happily (on the web) as a 64-bit Snow Leopard compatible executable, and (on my desktop) now with Growl support back integrated. I've also (thanks to some kind tweeters) found the solution to the Sparkle update errors, so in the next build + 1, those will be gone (it takes one intermediate build to fix the issues).

We have, however, very recently made some design change decisions about Bluebird, one of them being that we're going to move away from WebKit as the primary theming engine. WebKit is absolutely phenomenal, but when not properly optimized, it has the tendency to slow things down a bit and make the environment feel "less native." For that reason, we're developing a new Cocoa-based theme plug-in system.

The idea is that we'll create a standardized Objective-C/Cocoa API for themes, and only expect in return an NSView that we will display in the main part of the Bluebird window. In this way, themes are free to do absolutely whatever they want. We'll be including two (I think) Cocoa themes out the door so people can get to using Bluebird, and if people want to make more, we'll be publishing a full set of instructions. We decided that it is far more beneficial to have a speedy and native-feeling app than to have one that's fully customizable (although if you're willing to put in a bit more work, you actually have more control over customizability than you did before).

Now of course that does leave all of those people who've developed some relatively popular HTML-based themes for Bluebird in a bit of a tight spot. But fear not, we have a solution!

Because the new theming engine is Cocoa based, that means there's virtually no restriction on what a theme can do — including embedding WebKit, if it so desires (see where I'm going with this?). In order to ease the transition as much as possible, we'll be developing and sharing a WebKit theme "wrapper," with a tool that easily allows you to convert any HTML-based theme into a Cocoa theme with no more than the click of a few buttons. These themes will still suffer from the downsides of the current theme model (primarily speed and non-nativeness), but they should work no differently than they do currently.

So that's the new theme model in a nutshell: new Cocoa themes to improve speed, with an easy conversion tool so you can still use HTML-based themes if you want. I think it's a pretty good solution. :)

In order to further improve performance and decrease "internal ugliness," I also plan on rewriting one of the core tweet management classes to make it significantly more streamlined. On top of all that, we've trimmed even more fat off the UI, and we're working on building a new (FAST!) Direct Message view that we think you're gonna' like.

When are you going to get all of this? Hard to tell. We're working hard on it, but it's a lot of work. If I had to guess (and it is purely a guess), I'd say you can look forward to a new build of Bluebird (which we intend to be 1.0 final) by December.


Bowtie has experienced some minor pitfalls on Snow Leopard, some of which fall outside of the realm of explainable, so we're doing a lot to try to clean that up.

Bowtie will of course get the cursory minor feature upgrades previously promised: 64-bit (currently living happily in 64-bits on my desktop), multi-display support, lower memory usage (where possible), Exposé fixes, etc. However, most radical in Bowtie are the under-the-hood changes I've been making (and will continue to make).

The way Bowtie used to work, it would send kind of a "ping" (via Apple Events) to iTunes every second, expecting in return a unique string indicating the current track. If this string changed, that would mean the track changed, and Bowtie would then get information on the new track. It would also (every second) pull from iTunes status information, like playback position, volume, player state (playing, paused, stopped), etc. iTunes handles this kind of interaction like a champ, and it really does work OK (save a few small related bugs), but it isn't at all the most efficient way to communicate.

So we're changing things up in the next build. First of all, we're taking a step away from the old Carbon-heavy Apple Events model, reading the writing on the wall, and switching over to Scripting Bridge (before, I wasn't a huge fan, but after working with it for a month or so I'm quite fond of it). This will play a big part in future proofing Bowtie, and also hopefully will improve stability a little bit.

In addition, we're no longer polling iTunes for a lot of that information. OS X has an excellent system called "Distributed Notifications," which allows apps to post information about changes in state that can be observed by any running app or process on the system. Conveniently, iTunes posts Distributed Notifications — a lot of them, including whenever the track changes or the player state changes.

What that means is that Bowtie can start observing these notifications, and no longer needs to poll iTunes for information. Rather, iTunes will just tell Bowtie when it needs to update. Pretty simple, eh?

This will require a few small modifications to the internals of the theming engine (as some of the theme information will now be coming directly from Bowtie and not from iTunes anymore), which will take a little while, but should not affect the theme API: all existing themes should continue to work without changes. We will also be completely rewriting the Last.fm engine to use their newer API and hopefully clear up some of the scrobbling issues people have been seeing.

So when do you get all of this? Again, committing to release dates is a challenge, but my guess is that the 1.0 final build of Bowtie will also be hitting the shelves by December.


And of course, let's not forget our beloved Colors. It's a small app, but it's really useful to a lot of people, so I've made a concerted effort to clean things up significantly.

Colors has recently undergone some substantial changes, the most important being:

The bulk of the application works just fine, the only thing that really needs clean-up is the UI. We've got a few mock-ups in the shop (some by friend and graphic designer Olivier Charavel), but I feel like things still need a tiny bit of work before they're ready to be implemented.

So when do you get the newest build of Colors? Well see, here's the thing: the new features are really cool, and I don't want to deny you their use. So let's make a little deal: if you don't tell anyone, we'll call the current build — with a crappyish UI — Colors 1.9, release it today, and just release Colors 2.0 with an updated UI sometime in the not-to-distant future. Sound like a plan? Good, now head on over to my portfolio and download the latest build of Colors.

In Conclusion

I know, the release dates are a little far off, and that hurts me as much as it hurts you, but hopefully you all see that we're working really hard on ways to make all of our apps better than ever. Until next time!