Introduction and Disclaimer

The first in a three part series of taking a 1.0 application to 2.0.

Often on the macsb list, I see questions like “How much should I charge for my app?”. There is only one answer for this that will allow you to sleep well at night: “As much as you think that it is worth.” The story below details how I decided how much Screen Mimic 2.0 was going to be worth. This article will not help you at all in deciding how much to charge for your app, but if you’re tired of coding, then take a break and read it anyway.

Choosing the price for 2.0 was much harder for me than choosing the 1.0 price. When you are choosing the 1.0 price there is really no baseline. Sure, you can look at the prices of your competition, but the price that you set for your app is a subconscious message that you are sending about how much better/worse your app is then everyone else’s. You may not believe this, but it is true.

With a 2.0 release, you have to decide on two prices. Your base price, and your upgrade price. Do you offer a free upgrade or a discounted upgrade? Is the 2.0 price the same as the 1.0 price or is your app now worth more than it was before. (As a hint, if you are releasing a 2.0 app, it really should be worth more than your 1.0 release)

As you read this you may think to yourself, “when is he going to stop blabbing and start talking about why he went from $24.95 to $64.95? Well, to understand that decision, you need to understand the process that lead to it, so be patient and read on, soon all things shall be revealed to you…

In the beginning…

In December of 2005, Screen Mimic 1.0 was released. It took just over six months to write. The impetus for Screen Mimic came when I tried to download Macromedia/Adobe Captivate for the mac, I discovered that there wasn’t a mac version, so I decided to write my own.

Initial feedback was good, however there were a handful of features that people wanted that weren’t included in the 1.0 release, I’ll talk about feedback and features in part 2, however the 1.2 release included some of those features that people were asking for. It took another month to put out the 1.2 release, and it was a free upgrade.

Universal Binary, more than just “click the checkbox”…

Meanwhile, Apple began shipping Intel-based macs. If you are a mac developer that was a little slower getting on the Universal-Binary Bandwagon (UBB), you may have noticed a sharp decline in sales shortly after that announcement. (Maybe it was just me). People didn’t seem to want apps that weren’t universal binaries.

In February I got my hands on a MacBook Pro, and let me tell you that despite Steve Jobs’ assurances, it was no “click of the checkbox” experience for me. When you are dealing with low level pixel manipulations, byte order becomes a bit of a pain. Combine that with the fact that QuickTime wants it’s pixels in one order, and flash wants them in another, and you have some headaches to sort through. Even worse, Flash Video (FLV), handles byte order differently that regular Flash (SWF) files do. I can really understand why a war was started over this.

Despite all of these headaches, Screen Mimic 1.5, the universal binary version, was released in June of 2006. This took a considerable amount of time (5 months), for a number of reasons. The main reason being that I had started going to graduate school full time, and so I was back to nights and weekends coding. (It sounds a lot like a cell-phone plan, you can code all you want for free on nights and weekends…). Screen Mimic 1.5 was also a free upgrade (or cross-grade as some people liked to say during the Intel transition period).

On to Audio…

With the universal binary under my belt it was time to focus on Audio. Some of you reading this may wonder why audio wasn’t included in the first place, and why it took so long, after all, other screen recorders have audio support, how hard could it be?

Well, if I were writing a QuickTime only screen recorder, then believe me, it would have been easy to include audio, it would have been part of the 1.2 release. But I couldn’t stomach having audio in one of the three export formats, it didn’t feel right. So it was all or nothing.

To really understand this part of the struggle, you need to know some things about binary flash (SWF and FLV) files. Dealing with binary Flash files is a lot like trying to cross the plains with a map from the 1800’s that was written by a dozen different explorers some of which never actually left the east coast.

Yes, there is a specification available that you can get. Unfortunately some parts of it are contradictory, others parts are missing or just plain wrong, and some parts (especially some of the audio related parts) refer you to outside sources that mere mortals simply cannot access.

Once you have generated your file, if things aren’t working the right way, the only way to know why is to use a hex editor to look at the hex code, one byte at a time. Let me tell you how much fun that is. None. It is no fun at all. However, the work must go forward, so we do what we did.

Now, in the case of audio in flash files, as of the latest release (Flash Player 9), you have the following choices:

• Raw Audio - Raw, uncompressed audio, very easy, but very very large files.
• ADPCM - Smaller than raw, but still pretty big. Doesn’t work well for streaming sound. And just for fun, the Apple adpcm encoder that is built into QuickTime (aka IMA-ADPCM), isn’t the one that Flash uses, they are referring to the Microsoft adpcm format, which is NOT the same as Apple’s.
• MP3 - Small, great for streaming, but requires some hefty licensing fees.
• Nellymoser - Same as above, but heftier fees and closed spec.

In the end we decided to use MP3 because it had the cheapest licensing fees of the formats that were of any practical use for streaming audio.

Licensing Fees…

A common question that people ask when this comes up is, “Why don’t you just use LAME?, It’s free.” Well the fact of the matter is that we are using LAME for encoding the MP3 audio. However when you are licensing the MP3 codec, you aren’t licensing the source code to generate MP3 files, (although you can for an additional fee). You are licensing the right to create MP3 files.

If you are using LAME without an MP3 license, you are doing so illegally. You may think that is fine because “information wants to be free” or whatever warm fuzzy expression you want to use to rationalize getting something for nothing, but in a commercial app, that philosophy just doesn’t fly.

As a side note, if you are planning on making a living by selling intellectual property, you are shooting yourself in the foot if you don’t respect the intellectual property rights of others. Karma will catch up to you. And you will be forever doomed to software piracy hell.

The MP3 license involves a per unit fee, plus a minimum annual fee, so any decision regarding 2.0 pricing would have to include the ability to cover these costs.

Cocoa and audio

As I mentioned before, unless you are just playing system sounds, audio support in Cocoa is pretty lacking. There is no super easy [myAudioRecorder record] method. While CoreAudio is pretty neat, it has an amazingly steep learning curve, especially if you’ve never used audio before. So there was a large amount of time spent on learning audio, then learning CoreAudio, then learning how to tie that all into a Cocoa app.

While there are third party frameworks available such as MTCoreAudio that provide a Cocoa wrapper around CoreAudio, like most third party frameworsk, it wasn’t quite what we needed.

Pricing and Upgrades

Finally everything was done, it was time to decide on the price. I had already decided that this was going to be a 2.0 release, rather than a free 1.x upgrade. The question was how much to charge. Into the decision went factors such as the cost of other apps in this space, licensing fees and other expenses, but ultimately it came down to “How much do I think this is worth?”.

The decision was made. $64.95, with a $39.95 upgrade cost for 1.x users. This would give 1.x users a discount equal to the price that they paid for 1.x. Was this the right decision? Yes. How do I know? I know it was right for the following reasons:

1. This is the price that my wife first suggested.

My wife (and I suspect most women) has an amazing ability to ascertain the worth of something. Whereas I am more inclined to base worth on the number of blinking lights or buttons something has, my wife can see past these things to gauge the true worth of something.

When we look at furniture for example, I think, “$1000 for a sofa! It doesn’t do anything, there aren’t even any buttons on it. I could buy two mac mini’s for that price!”.

2. People are buying the app at this price.

I won’t give out exact numbers, but sales have doubled since the 2.0 release. I’m not saying this to brag, but to let you know that while you may think when you charge more you will sell less, that simply isn’t true. Now this increase could be attributed simply to the inclusion of audio, but the fact of the matter is that sales have doubled.

3. A small number of people (very small) have complained about the price.

Something that I picked up from the developer panel at the O’Reilly conference (that may also seem counter-intuitive) was that if no one is complaining about the price, you aren’t charging enough.

The main reason however that I know that I am charging enough for my app is the same reason that you will know you are charging enough for your app. It is because I am charging what I think my app is worth.