Monthly Archives: February 2010

5 by 5


I first met Dan Benjamin in 2005, at an off-site meeting for VitalSource in Telluride, Colorado. I don’t remember much of what we talked about over the course of those few days, but what I do remember, as the team was riding in the back of a jeep heading up the mountains, is that he kept talking about radio and podcasting.

In the five years since then he’s started a couple successful podcasts, and now he’s launched something bigger: a podcast network called 5 by 5 with a strong lineup of new shows.

“I started planning. I didn’t want to do it part time or half way — I wanted to do this for real, meaning full-time. I wanted to create an Internet-based broadcast network, a place where I could create and host shows for myself and with my friends.”

I love seeing someone’s passion, only loosely related to how they earn a living, go from something in the back of their head to a full core business. Good luck, Dan. It’s off to a great start.

I don’t use Core Data either

“Brent writes a fair post”: on when Core Data is great and when it’s a performance bottleneck:

“I optimized as much as I could, spent tons of time in Shark, went all multi-threaded with Core Data, switched away from my own queuing system to NSOperationQueue, optimized the XML parsing, etc. But performance and memory use on my first-generation iPod Touch (my development test device) was still not nearly good enough with a big unread count (of around 10,000 items).”

If I had been writing that post I probably wouldn’t have praised Core Data as much as he did, although admittedly because I rarely use it, and not at all in any shipping applications. Its approach always seemed slightly wrong to me.

My main reason for sticking with SQL directly is that I know by coding at this lower level — with my own lightweight model objects on top of FMDB and utility methods for working with the Clipstart database — that if something is slow it’s my fault. I can fix things that are my fault. I can’t fix fundamental design problems in Apple’s code.


My quote from “Cult of Mac”: sums up my feelings about the iPad from a business perspective:

“I was so annoyed with the closed nature of the App Store that I stopped developing for the iPhone. The iPad will still have those frustrations, but the large screen opens up a whole new class of applications. It’s impossible to resist.”

Will there be a “Clipstart”: for iPad? I hope so. This platform will be the future for plenty of customers. Apple lived up to the hype not because of the hardware or distribution or anything entirely revolutionary, but because of the software. Splitviews and popovers. Keynote and Pages. These apps are just as competent as their desktop versions.

Daniel and I talked about the iPad for most of “Core Intuition 26”:

ParseKit (and Clipstart search)

The first couple versions of “Clipstart”: had a very basic search feature. You could enter keywords and it would search filenames, tags, and video titles. You could also enter special terms such as tags=christmas or imported=today, but you couldn’t mix and match different terms together.

When I started working on a more advanced search parser, I realized that I was about to write a bunch of code that surely someone had already generalized and shared with the world. Tada! “ParseKit”: by Todd Ditchendorf is that framework.

Clipstart 1.3 now supports these kind of searches:

christmas and (@julian or @kids)


(uploaded=no and flagged=yes) or (date=2010 and @vacation)

I use ParseKit’s tokenizer to take these apart and then I translate to SQL myself for SQLite. New in 1.3, Clipstart also allows saving any search as a “smart tag” for quick access. I’m very happy with how well it’s working.

Why not use “NSPredicate”: and friends? I wanted more control over the parser, for example for the @kids shorthand for tags. Eventually I’ll have a more traditional NSPredicateEditor-like UI for managing searches, but I find that text input is a much quicker way to find things in my video library.

Removing features

“Lukas Mathis writes”: about removing features:

“You don’t _have_ to try to please everybody and eventually create an application that is liked by nobody. In fact, since your users are in all likelihood in a situation where they can switch applications easily, and since they probably are not locked in by the need to open a specific file format in its native application, it might be a really bad idea for you to go down the ‘simply add up all the requested features’ route of application design.”

He also links to “my Wii Transfer survey”:, so I thought I’d post a quick follow-up. I eventually did remove a feature, and the survey to customers served as a nice sanity check that the feature wasn’t heavily used. The interesting part, to me, is that the feature I removed was the entire 1.0 product for Wii Transfer. Literally everything that 1.0 did is now gone.

It’s been two weeks so far without any complaints. I like to think that it removes a distraction from the app — one less place in the app that could lead the customer down the wrong path. And hopefully it’ll eliminate a tiny part of my support load, as no one can ask me questions or have problems with that feature again!

On an internal company mailing list I once wrote:

“Products that don’t exist yet have a way of attracting new features because everyone sees the potential in something that has no form”.

I was talking about resisting the urge for everyone on the team to pile on their favorite features before 1.0, but I think this applies to apps with a minimal design as well. A simple app shows promise. A cluttered app with too much going on looks “done”, and sends a message that it is mature and maybe going in a different direction than what the user wants. In that way, the irony is that removing features (the wrong features) may actually make an application more appealing to new users.

Bodega bootstrap

I wrote the following before the iPad was announced. The world may have changed since then, but I’m posting it anyway. Enjoy.

I like the content but not the title in “John Casasanta’s blog post about the so-called death of Mac software”: He shares some great stats and lays out the case for why iPhone development is more appealing and successful for him, but that doesn’t make the Mac dead. What he really meant and says later is that it’s dead to him.

For those of us who love writing Mac software and who don’t feel the pull of get-rich-quick blockbuster apps, the Mac is alive and remains just as healthy as it was before the iPhone was announced.

That’s not what I want to write about, though. The real question is how do we learn from the App Store and expand the market for Mac software. Compared to the iPhone, the Mac has a fragmented application discovery and an inconsistent purchasing experience.

When Keith Alperin and Rick Fillion “talked on the MDN Show”: about a possible Mac app store, Rick revealed some interesting numbers from “Bodega’s”: installed base: 80,000 downloads and 10,000 active users. They’re not 1.0, and I don’t see anything wrong with these numbers, but it’s not big enough yet to make an iPhone-like impact on how we buy Mac software.

What Bodega does have is a technology head start. “My products”: have been listed there since launch, and they have a polished application and feature-rich backend for tracking releases and collecting usage metrics. The key is solving the chicken-and-egg problem of getting the Bodega app in everyone’s hands.

There are two approaches: either get people excited about installing Bodega because it’s useful for updating existing apps (which it is), or sneak a copy of Bodega on to many more Macs (which is what this post is about). This solution isn’t perfect, but short of Apple building a real Mac App Store or a marketing giant like MacHeist getting involved, it’s the only idea I can see working.

First, start with “PotionStorefront”: There are a few of these in-app purchase frameworks out there, but I like the “Potion Factory’s aesthetic”: and Potion Store is popular. The web service used to submit orders could be supported by other custom store backends, including Bodega’s own purchasing system when they have it.

On top of this in-app purchase foundation, you bundle a subset of the Bodega application discovery UI directly into the framework. Users can download and install demo versions of new apps without leaving the catalog. Think of it as a “lite” version of Bodega, streamlined to fit inside everyone’s app. You also include the full Bodega application so that it can be launched and optionally installed in the user’s applications folder.

What you’ve effectively done here is give everyone who buys a third-party app access to a new store where they can discover other apps. It’s compelling for developers because the more companies that participate, the wider their reach becomes. And it’s great for users because over time it starts to create a consistent user experience, and familiarity reduces the effort in buying Mac software.

Some tricky issues remain, though. You don’t want to distract users from buying their first application, or muddle that app’s branding, and you want to later encourage users to find or be notified about new applications without it looking like an advertisement. The challenge is in finding a balance that most developers would want to use.

Back to the iPhone’s success, from a post by “Guy English”:

“People, lots and lots of people, people who have no idea what software even is, will download Apps like they’re snacking on potatoe chips. What’s my proof? Well, two million downloads of an App in a week supports that and I’d argue that a total of three billion Apps downloaded backs up my argument too.”

We’ve never seen anything like it, and I’m really happy for my friends who have had success on the iPhone. Luckily, the iPhone and Mac don’t actually compete. The App Store can sell ten thousand times the amount of software as the Mac does and it doesn’t change the fact that Mac users need software too. It’s our job as developers to continue to provide solutions for users and help those users find us.