Patrick Rhone

I’m willing to pay far more for an item if I know it will last a lifetime and, even more importantly to me, I will never have to spend the mental energy making a choice again.

This is such an unbelievably huge power move. I agree that big ticket items should be carefully considered. Right now, I’m in the midst of just this process with my needing to buy new clothes. I plan to buy things that will wear well and for a long long time. I discovered this benefit initially after receiving a Levenger Circa notebook as a gift a few years back. I still have, use, and love that notebook and foresee having it for many more.

While Patrick is spot on about final choices, I would add that it also goes for things you buy on a more frequent basis as well. For instance, I never think about what pencil I’m going to buy and use. I know I use Uniball Kuru Toga pencils. (Thanks to Patrick for turning me on to these as well.) If I lose, break, or for some other reason find myself needing to buy a pencil, I don’t go to Staples and gawk for an hour at the wall of mechanical pencils. I hop on the Amazon app on my iPhone while I’m waiting in line at Starbucks and order a couple to show up at my door step in two days.

This is something that I’ve termed “sensible defaults.” It’s a phrase I’ve picked up from studying UI design principles, but it’s something I’ve been able to work into other areas of my life as well. For instance, by picking sensible defaults at the eateries we frequent I was able to lose 50 pounds last year.

Is it a little neurotic? Absolutely. Does it mean you might spend a few weeks or months on a quest for the perfect bag to carry around your kit? Boy, ask my wife. Does it mean you might miss out trying the hot new dish at Pei Wei or the new exercise craze? Indubitably. But, in my opinion, the tranquility is well worth that opportunity cost. And the potential for doing something awesome with the saved time and neurocycles is priceless.

I’ve been working on my first indie Mac app in my spare nights and weekends for several months. Just as I’m nearing the 1.0 release, Apple announces the Mac App Store. Oh boy… This is sort of a perfect storm. I don’t have any existing customers or really much of anything that can’t be ripped out to go the Mac App Store route.


I have a kickass full time gig with Agile Web Solutions working on awesome stuff that is tons of fun. So, I’m not necessarily looking for my indie work to support Ann Margaret and me full time. My goal is still rather lofty, but it’s one that is 100% measurable: I want to pay off our student loans sometime before one of us dies. We’re two well educated people with three bachelor’s degrees and three and a half master’s degress between us, so the number is pretty hefty, but it’s definitely a target that’s not likely to move much.

Enough Theorizing. Let’s use numbers.

Before the Mac App Store, I was targeting a $25 price point for my app and planning to use FastSpring as the payment processor. I figure that by the time I offer discounts, promotions and whatnot that I’d like to get 80% of that, so $20. For simplicity, let’s say FastSpring takes 10%. That’s $18. Now, I want to consider that Uncle Sam gets his cut too, so let’s call that 25%. So, for each license I sell, I get to apply $13.50 of dynamite to the mountain.

With the Mac App Store, Apple gets 30% of the sale price. So, a $20 price point becomes $14, which then becomes $10.50 of useful income.

But wait a minute, can I sell my app for $20 on the Mac App Store? If Apple’s keynote is any indication, that’s not going to work. The iLife and iWork apps are shown in the keynote video as selling for $14.99 and $19.99 each respectively. Users will perceive that Pages or Keynote is infinitely more complex than my app, so how can I “get away” with charging the same price? In the past, my argument was that the iLife and iWork bundles were priced as low as they are because it’s the price Apple perceives folks would pay for the one or two apps in the suite that they were really after. The individual pricing of apps on the Mac App Store screens in the keynote makes that argument no longer hold water.

Assuming that is true, let’s say I drop the price to a nice $9.99 price point. Apple gets $3 leaving me $6.99, from which I have to pay taxes leaving a net of $5.24. I really cannot envision selling my app for less than $9.99…

The Arguments for Mac App Store and My Answers

  1. Low Overhead It’s true you don’t have to write license and trial code. But, I have been working with CocoaFob and it’s just fine. Trials are a little trickier, but it’s not hard to implement something there. I already have a time limitation in my app and just need to add a few additional tweaks. I have my own hosting account with Dreamhost that has unlimited storage and unlimited bandwidth, so I don’t worry about those aspects either. So, I consider the low overhead argument moot.
  2. Increased Exposure/Cog in the Apple Machine I think this argument is simply overvalued. Lukas Mathis rightly points out that the App Store as it exists for iOS is simply terrible for discovering apps. I hadn’t considered it but the point Lukas makes about pirate stores being a better, more curated experience for users is fascinating and depressing all at once.

Arguments Against Mac App Store

The Mac App Store is not without its drawbacks, but unlike the iOS App Store, there really is a viable alternative where one can sell an app without being in the App Store.

  1. No integrated free trial system Yes, in theory you could provide a free trial download on your website, but this is something that Apple needs to bundle in as it is part of the user’s experience and there are millions of users who are well accustomed to the free trial model on the Mac.
  2. Customer distance With providers like FastSpring, you get access to the user database. Apple keeps that under wraps so you can’t know anything about your customers. What Apple is saying is, “These are not your customers. They’re ours.” This makes things like cross selling nearly impossible and things like newsletters and customer interaction an additional step for the user during first launch or some other time.
  3. No paid upgrade path As far as I know, it’s the same situation as on iOS. This has caused a lot of trouble for a lot of developers there and on the Mac, it will be the same situation without some significant changes.
  4. Some types of software can’t be sold If the appeal of the Mac App Store is that you don’t have to do all this overhead of licenses and trials and whatnot, what happens if I want to develop a prefpane or a Photoshop or RapidWeaver plugin? Oh, now I have to do all that stuff that Apple was supposed to handle, and as a result, that benefit is nullified for all development.

The Question

Is it reasonable to expect that I could sell two and a half times as many copies of my app in the Mac App Store?

I’ve been working on making the Javascript for a pretty big Rails app unobtrusive. Chucking everything into application.js as shown in many screencasts with trivial apps has proven to be problematic to say the least. It’s brittle code that could very well infiltrate unintended areas of the site that happen to use the same classes or id’s. Bad juju.

What I find amazing is that Rails hasn’t developed a convention for Javascript.1 I’ll describe some approaches I’ve seen and then the approach I developed.

Namespaces 2

This approach still chucks everything into just one or maybe a few big js files, but uses namespacing to get around the potential conflicts. As far as I can tell, though, this approach requires that the user use the next approach via a helper method.


This is old news and we use it to great effect, but it has drawbacks because it does not rely on convention over configuration. Also, if you have a few <%= yield :foo %> areas, your actions become a muddle of template code and actual action code. Currently we’re using content_for for a few different areas of the page, and it’s already becoming messy in the actions.

Convention over Configuration 3

# application_controller.rb
before_filter :instantiate_action_javascript
def instantiate_action_javascript
    js_path = File.join(controller_path, "#{action_name}.js")
    @current_action_javascript_path = File.exist?(File.join(RAILS_ROOT, 'public', 'javascripts', js_path)) ? js_path : nil

# layout.html.erb
<%= @current_action_javascript_path ? javascript_include_tag(@current_action_javascript_path) : "" %>

The code should speak for itself, but I think that mimicking the structure of the views directory makes the most sense here. With this code, I can create javascript files for each action and have them automatically included in the template. Checking for the existence of the file prevents an unnecessary HTTP request and corresponding 404 error in the Javascript console.

  1. We’re still on Rails 2.3.10, so if this is in Rails 3 (or I’ve simply missed it in Rails 2) please let me know. 
  2. First found this at Toby Hede’s blog via this SO post 
  3. I haven’t seen this anywhere else, but I’m certainly not so clever that I think no one else has thought of it.