Step 1: Sign up as an iTunes Affiliate

First you’ll need an affiliate account, so go to Apple’s iTunes Affiliates page and click on “Apply to be an affiliate,” which will take you to LinkShare. The sign up process asks for your company and website information.

You’ll need to apply to advertise for “Apple iTunes.” I don’t remember how long it took me to be approved, but I think it was less than 24 hours. They do check the website you provided to make sure it is legit. I have heard that they will reject your application if the website is just a placeholder or if it has trademarked names in the URL, such as “iPhone.”

You need a LinkShare account because Apple has provided LinkShare hooks into the App Store so it knows when a click turns into an actual sale. As a bonus you’ll earn a 5% commission.

Step 2: Create a LinkShare link for your app

Next, you’ll need to create a LinkShare link to your app in the App Store. Using this link will allow LinkShare to magically know if a click turns into a sale.

In LinkShare, select the Links > Deep Linking menu item, and select Apple iTunes as the advertiser. Enter your app’s iTunes URL in the URL field. Don’t worry about the U1 Value field right now, you can just leave it blank. Click Create Link and copy the resulting URL.

On your product page, wherever you link to your app in the App Store, use your LinkShare link instead. If you stop here, LinkShare will be able to track how many clicks from your product page result in sales. This is useful in itself, but it would be even better if you could track each promotion separately, and know how many sales a specific ad resulted in.

LinkShare supports ad/promotion tracking through “signatures” which is what the U1 Value field above was all about. Signatures are simply a user defined string that are passed to LinkShare via in the u1 URL parameter.

Step 3: Tracking referrers through the product page

When creating ads or links to your product, you’ll probably want to direct potential customers to your app’s product page on your website instead of directly to the App Store. This allows you to provide a video of your app, cross promote other products or services, or actually use HTML formatting. The complication that arises from this is remembering which ad the user clicked on to get to your product page by the time they get to the App Store.

The first step here is to know how the potential customer got to your product page to begin with. The easiest way to do that is to simply add on a URL parameter for the referrer and give each ad or promotion a different parameter value, which we’ll call a “signature.” For example, an ad for Hearts Attack could use this URL:

http://www.orderndev.com/hearts-attack.html?u1=GAD001

Here the referrer parameter name is u1, just to be consistent with LinkShare, and the ad signature is GAD001.

Next, you need to get the ad signature passed on to LinkShare. This is done through the u1 URL parameter, so you will need to modify any LinkShare URLs on your product page based on the signature parameter. You can do this either server side or client side in JavaScript. Dan Wood talks about how to track referrers server side for Mac apps, and his examples can be modified to work here. I chose to modify the LinkShare URLs client side using JavaScript. The basic algorithm is:

1. Check for the u1 URL parameter. If it exists save it off into a cookie.
2. Check for the signature cookie. If it exists, append “&u1=signature” to the LinkShare URLs.

At the bottom of my product page, I have code that looks like this:

	<script type="text/javascript">
		saveParameterInCookie('u1', 'hearts-attack-src');
		restoreCookieToParameterInAnchor('u1', 'hearts-attack-src', 'buy-link');
		restoreCookieToParameterInAnchor('u1', 'hearts-attack-src', 'app-store-link');
	</script>

The first line saves the URL parameter named u1 into a cookie named ‘hearts-attack-src.’ The next two lines update anchor tags in the HTML by appending the value of the signature cookie as an URL parameter. The second line says: update the ‘buy-link’ anchor tag by taking the contents of the ‘hearts-attack-src’ cookie as the value for the ‘u1′ parameter and appending it to the anchor tag’s URL.

Here’s the code for implementing saveParameterInCookie and restoreCookieToParameterInAnchor:

function getURLParameter(name) {
	name = name.replace(/[\[]/,"\\\[").replace(/[\]]/,"\\\]");
	var regexS = "[\\?&]"+name+"=([^&#]*)";
	var regex = new RegExp(regexS);
	var results = regex.exec(window.location.href);
	if (results == null)
		return null;
	else
		return results[1];
}

function addParameterToURL(url, name, value) {
	if ( value == null )
		return url;
	return '' + url + '&' + name + "=" + value;
}

function saveParameterInCookie(parameterName, cookieName) {
	var parameter = getURLParameter(parameterName);
	if ( parameter == null )
		return;

	createCookie(cookieName, parameter, 180);
}

function restoreCookieToParameterInAnchor(parameterName, cookieName, anchorName) {
	var cookie = readCookie(cookieName);
	if ( cookie == null )
		return;

	link = document.getElementById(anchorName);
	link.href = addParameterToURL(link.href, parameterName, cookie);
}

Hopefully the code is self-explanatory. It relies on functions createCookie and readCookie, which I got from this article on JavaScript cookies. I should also point out I am not a professional JavaScripter, so there may be bugs in the code. I make no guarantees about this code.

As complicated as all that might have seemed, you are now tracking potential customers from your ads or promotions, to your product page, to the App Store where LinkShare knows if they are actually buying or not.

Step 4: Tracking the performance of ads or promotions

The final step is viewing the results of your ad or promotion in LinkShare. LinkShare will be able to tell you how many visitors actually made it to the App Store, and how many of those actually bought something. To know how many visitors an ad or promotion is driving to your product page, you’ll need to use something like Mint or Google Analytics.

In LinkShare select the Reports > Advanced Reports menu item. Select the “Signature Activity” report type, and click View Report. You’ll get a table that looks like this:

The Member ID column is where your ad or promotion signature will show up. It will be whatever you pass to LinkShare via the u1 URL parameter. It also shows how many clicks the link got, and how much sales it generated. As you can see, my ads aren’t doing so hot, but at least I know that now.

Oops, sorry, wrong graphic. I meant this one:

Hmmm… not much difference really. As you can see I actually sold nothing on Sunday. Apparently everyone was interpreting “day of rest” as “don’t buy any iPhone apps today.”

This article is kind of a postmortem for the launch of Hearts Attack. I attempted a few different things in order to drum up sales. Some were more successful than others.

• One of the things I did before the launch was some search engine optimization on the Hearts Attack product page. Dan Wood of Karelia has some good resources on how to do SEO.

  I was fairly pleased with the results. The product page ended up on the first results page for a few of the keywords I was targeting. It could be better, but not bad for a PageRank amateur such as myself.

• On the day of launch, I issued a press release through prMac. I opted for their “extended press release” which sends the press release the same day and to more people. It’s only $20 so it’s low risk.

  I did see a couple of obvious benefits from this. The first benefit is “link juice” to the Hearts Attack product page and our company website in general. I had done some SEO earlier and discovered the biggest thing we were in need of was links. This helped immensely with that.

  Secondly, I mentioned in the press release that promotional codes were available upon request. Only three people ever asked for them, but I happily gave them away. I have not seen any reviews as a result, but hopefully at least I garnered some good will among reviewers.

  Speaking of reviewers, one thing I did not have ready at launch, that I should have, was a press kit. I kept mine simple in that it just contains screenshots and images of the app icon. I should have linked to it in the press release and product page, because it was something the reviewers immediately asked for.

  It terms of how many sales were made because of the press release, I don’t know. It did noticeably increase traffic to our site, but I didn’t have LinkShare hooked up at the time, so I don’t know how many of those visitors became customers.

• I wrote about Hearts Attack here and tweeted about it. I both published my own press release and then followed up with the story about Hearts Attack came about.

  This drove a decent amount of traffic to our website, and resulted in a few sales from my friends and other people who follow me on Twitter. Like the press release, it also helped with the “link juice” of our website.

• I asked my wife, Elaine, to write about it on Facebook since she has approximately 30 bazillion friends on there and I have none. Some say this is because I haven’t even created an account, but I think Facebook is just being stuck up.

  Anywho, this didn’t create much traffic, but it did create a couple of sales from friends who follow Elaine on Facebook, but not me on Twitter.

Of course the biggest driver of sales is being listed at the top in the App Store, which by default is sorted by the release date. Unfortunately being at the top is fated to be temporary, and I could easily tell when I fell down the list by looking at my sales.

In summary, I learned: I should have had LinkShare up and running to begin with so I could properly track conversions and know what approach is the most successful as far as sales. Second, I should have a press kit ready at launch and linked to it from the press release.

Way back in 2008 the original iPhone SDK came out, and I, like a lot of people, was excited about developing apps for the iPhone. My company is primarily a software development services company so I was mainly interested in learning the SDK so we could pick up iPhone contracts in addition to Mac ones. It also happens to be the case that my favorite card game is hearts, so I decided a good way to learn the iPhone SDK was to write my own hearts game.

After a couple of weeks I had the basic functionality implemented, and noticed I was playing it a lot. I realized then that I could probably make this into a product. Furthermore, releasing an iPhone app through the App Store seemed like a good way for us as a company to begin making the transition from a services based company to a product based one.

If I was going to release Hearts Attack as a published app, I knew the UI and presentation had to be greatly improved. I went through a lot of mockups for the main playing view, including one where everyone’s cards — all 52 of them — were always visible somewhere on the table (a truly horrible idea). Unfortunately I don’t seem to have most of the mockups around anymore, but I found a couple which you can see below. (See the product page for the end result.)

The biggest challenge I had was fitting everything on the screen and it still being legible and usable. By trial and error I figured out how small I could make the cards and still make them tappable, as well as their optimal position to make them accessible with one hand.

I began thinking about what would make Hearts Attack unique or different from its competitors. Back then there were literally just two iPhone hearts games in the App Store, and I felt pretty confident that what I had was already better than them, but I wanted to be sure. I decided on: oddball talking computer opponents, a tutorial that gave not only card suggestions but the rationale behind the choice (a pet peeve of mine), and multiple undo support for mis-taps and tactical errors.

The last step was to get professionals to do the sound and graphics. I ended up hiring a sound designer, a graphics designer, and a character illustrator. The sound design went smoothly, but getting the graphics done was a lot more involved than I anticipated, which is another story for another day. Jordan of OneToad Design created the app icon, playing backgrounds, and the special card backgrounds for the queen of spades and jack of diamonds. Lara Kehler did the character illustrations, which turned out great.

Unfortunately, Hearts Attack went on hiatus in early 2009. I was working full time on an iPhone contract, and simply didn’t have a lot of time to put into Hearts. Secondly, I had lost all desire in finishing it. It was becoming increasingly apparent that iPhone users didn’t want to pay more than $0.99 for anything, despite all the whining I did about it. I convinced myself it wasn’t worth releasing Hearts because it would never make back the money it cost us to make. Hearts stayed dormant for an entire year.

A couple of months ago, I decided to pick Hearts Attack back up again. I had the time and, as someone pointed out to me, it would never make money if I didn’t release it. I was tempted to update the app to the latest SDK (I started Hearts back before you could even use nibs on the iPhone) and add some features. I decided against this, because I really just wanted to ship it. I did have to update it to the 2.2.1 SDK because the current Xcode tools no longer ship with the 2.0 SDK.

Instead I focused on fixing the bugs and adding polish. Fortunately for me my wife happens to be a professional software tester with iPhone experience, so I got lots of good bugs to fix. I also prepared a press release, created a website, and otherwise got ready for the release. After I felt the app was stable enough, I submitted it to Apple on Friday. It was approved on Monday.

At this point, I’m still not convinced I’ll ever make back the money we spent on sound and graphic designers. A hearts card game simply is never going to be a big seller, and price point isn’t high enough to make up for that. Right now, I’m tending to think pessimistically about sales, but I’m going to do what I can to drum up sales and see how things go.

It’s a “wait and see” situation as to if we develop any more iPhone applications to sell ourselves. Of course, regardless of how well Hearts Attack does, we’d be happy to develop your iPhone app for you.

The player competes against three of seven possible colorful computer opponents, each of which has their own distinct looks and personality. The personalities range from a communist kitten trying to overthrow oppressive humans to a vegetarian vampire to a pacifist pirate who sells insurance. They always have something interesting to say about how they and their opponents are playing. The computer opponents can be configured to play at trivial, easy, normal, or hard difficulty levels.

Unique to Hearts Attack is its in-depth tutorial system. The tutorial begins by giving the player a brief introduction to the rules and strategies of hearts. Throughout the game it offers suggestions for which cards to pass or play, including the rationale for choosing those cards. The suggestions are useful to beginners learning how to play, and to more advanced players looking to improve their game. The suggestions can be used apart from the tutorial.

Since players always have their favorite way of playing hearts, Hearts Attack allows flexible configuration of the rules. Players can choose how cards are passed, which player leads and with what card, how penalty and bonus cards are scored, and what is required to shoot the moon or the sun.

Device Requirements

• iPhone or iPod touch
• Requires iPhone OS 2.2.1 or later
• 4.7 MB

Pricing and Availability

Hearts Attack 1.0 is $2.99 (USD) and available exclusively through the App Store in the Games category. Review copies are available upon request.

Links

• Order N Development, LLC
• Hearts Attack 1.0
• Purchase and Download

Company Information

Order N Development, LLC is a software engineering company providing contracting services for the Macintosh, iPhone, and iPad platforms. Order N Development was founded in 2002 in Dallas, TX by a small band of experienced Mac developers. Copyright 2002-2010 Order N Development, LLC. All Rights Reserved. Apple, and the Apple logo are registered trademarks of Apple Computer in the U.S. and/or other countries.

This year they aren’t content with bringing conference justice to only the UK, so they’re branching out to the good ‘ole U.S. of A. by way of Atlanta, GA. To help you decide which conference you should attend, US or Europe, I’ve prepared the following quiz:

1. What is your opinion of Seattle?

   1. It’s nice, but isn’t nearly rainy or dreary enough.
   2. I like their coffee.
   3. The residents have too many teeth.

2. Describe your driving habits

   1. I like to drive on the left side of the road.
   2. I like to drive on both sides of the road.
   3. I like to merge right six lanes without signaling while going 147 mph on the off ramp and giving the finger with both hands in my black Camaro.

3. The pinnacle of human achievement is…

   1. Afternoon tea
   2. Sliced bread
   3. Hee Haw

Scoring: Give yourself -1 points for any 1 answer, 0 points for any 2 answer, and 1 point for any 3 answer.

If you scored is less than zero, you should attend NSConference Europe; if greater than zero, NSConference USA. If you scored exactly zero, you are truly a cultured individual and should attend both.

Personally, I’ll be attending both, and not just because of peer pressure and insightful quizzes. I’ll be presenting a talk on how to implement a watercolor brush using Core Image and OpenCL and maybe some duct tape. If you enjoy the graphics articles that I post here, you’ll probably enjoy my presentation. If not, I hear Steve “I’m Batman” Scott does a mean Adam West impression.

Not too long ago I was profiling an iPhone app that I had written for a client. Their testers had found that using a certain feature for long enough ended up causing the app to be ejected because of a low memory situation.

After some quality, yet painful, time with Instruments I discovered I was never deallocating image memory in the form of CGImageRef and its internal drawing cache. (It turns out that if you draw a CGImageRef while on a thread other than the main thread, it creates a cache of the bitmap data. However, this wasn’t my problem.)

At first I thought I simply forgot to release the UIImages somewhere. I put in some logging code and was able to confirm that I was releasing the UIImages the correct number of times, in the right places. But it appeared that someone had called retain on it an extra time.

That’s when I happened to notice that only the UIImages I had constructed with imageNamed: were failing to be released. I suspected that they were being retained in a global cache. The only problem with this cache is not released in low memory situations. Even when my app receives a low memory notification and I free up all the memory I can, the UIImage global cache just sits there clutching it’s unused UIImages to its chest, muttering.

Unfortunately for me, some of the UIImages I was loading were large, and I was expecting them to be deallocated when I released them. As the feature was used, different UIImages were loaded with imageNamed: and never released until the phone ran out of memory and my app was ejected.

The solution was to write a replacement method for imageNamed: that didn’t cache the UIImage. Here’s what it looks like:

@implementation UIImage (OrderNDev)

+ (id) imageNamedNoCache:(NSString *)name
{
	NSString *basename = [name stringByDeletingPathExtension];
	NSString *extension = [name pathExtension];
	NSString *path = [[NSBundle mainBundle] pathForResource:basename ofType:extension];
	return [[[UIImage alloc] initWithContentsOfFile:path] autorelease];
}

@end

The moral of the story is imageNamed: is only for use with small images that are used constantly throughout the app’s lifetime. Don’t use imageNamed: if you want that memory back on a 2.x device. Everything will work fine on a 3.x device though.

It also occurred to me that other developers might be gathering this information, so I thought I’d post what I’ve found so far here. I got the idea from MobileOrchard.

General iPhone Sites

1. AppCraver
2. 148Apps
3. App afari
4. Apple iPhone Apps
5. iPhone Application List
6. NativeiPhoneApps
7. iPhone Apps UK
8. apptism
9. What’s on iPhone
10. iPhone Alley
11. got apps?
12. iPhone Footprint
13. Zym Blog
14. RazorianFly
15. iGames
16. touchtip
17. iPhone Journal
18. iPhone in Canada

iPhone Game Specific Sites

1. touchArcade
2. Pocket Gamer
3. TiltGamer
4. Finger Gaming
5. Slide to Play
6. IGN Wireless
7. iPhone Games Network

Note that these sites do reviews, sell advertising, and/or have a place to submit an app for listing. I’m not including sites that do general iPhone reporting, but wouldn’t be appropriate for PR or advertising.

If you know of others, please feel free to leave links to them in the comments.

This is a description of my experiences with finding and hiring a sound designer to create royalty free, custom sound effects for my game. My experience with hiring and working with a sound designer was quite pleasant. The entire process was completed exactly one week after I first started contacting designers.

Preparation

Before I started contacting designers I sat down to figure out what exactly I needed from the sound designer, and what information he or she would probably need from me. I’ve never worked with sound designers before, so I had to make some educated guesses. In the end, my guesses seemed to be at least adequate. I wrote down everything I thought the designer would need in a specification document.

The specification document I create was pretty simple; it had two sections: an introduction and a description of the sounds. In the introduction I gave a brief overview of the game, how the sounds were going to be used, the “theme” I wanted, and a total count of sounds to be created. I managed to fit this into five sentences, on the assumption that the designer wanted to know about the sounds, and not my life story, fascinating as it is.

For each of the sounds, I created a description for it. I gave each sound a short, unique name so they were easy to refer to. I then described what the sound was, for real world sounds (e.g. card placed on a table), or what I wanted it to sound like, for abstract sounds (e.g. a sharp, clicking sound). I also tried to give the context in which the sound will be played (e.g. when a button is pushed). Finally, I stated the length I wanted the sound to be. Most of mine were only one or two seconds in duration.

Selecting the contestants

With the sound specs in hand, I was ready to start contacting designers. The only problem was that I didn’t know any, nor had I heard of anyone recommending any. Being put in such a desperate situation, I did what any engineer would do — I googled for some, and blogged about it. In the end, I contacted three different sound designers:

• SoundRangers
• Sound for Games Interactive
• IndieSFX

I originally found about six companies that I thought could possibly do the work, but I whittled down the choices to these by using the following criteria:

1. Did it look like the designer had experience creating sound effects for games? Since that was what I wanted, it made sense to see if their portfolio reflected that.
2. Could I navigate the designer’s site well enough to actually find a way to contact them? I didn’t originally intend for this be criteria, but it ended up being one. Advice for sound designers: hire a good web designer.

For each of the three designers I selected, I sent out an introductory email. In the email, I briefly described the project and asked if they were available and interested. I mentioned that I had a spec and would like a rough estimate before work began. In retrospect, I should have probably attached the sound specification to the introductory email, because that was the first thing everyone who was interested ask for.

Of the three designers I contacted, SoundRangers and IndieSFX replied to me within 24 hours. Sound for Games never got back to me. SoundRangers and IndieSFX charge by the sound, and offer both stock and custom sounds. For stock sounds, prices range from around $1 to $5 per sound, although IndieSFX only sells them in packs. For custom sounds, prices range from $10 to $40 per sound. None of the stock sounds were quite what I wanted, so I elected to go for all custom sounds.

Between SoundRangers and IndieSFX, I chose IndieSFX. Both seemed to be comparable in quality, but IndieSFX had better prices.

Creating the sounds

Once I had signed a contract for IndieSFX to create the sounds, I began working with Mark to do just that. Based on my specification, Mark created a first draft of the sounds by the next day. Some sounds had multiple variations for me to pick from, while others I was just given one choice to refine.

Mark and I went through about seven or eight different variations of the sounds before we settled on something. In general, I got a new revision of the sounds every day, which was highly motivating.

Along the way I learned a couple of things about sound. First, there’s the concept of “wet” versus “dry” sounds. Wet sounds have more echo and reverb and, at least in my case, sounded better. Dry sounds are shorter, which can be good if you have a tight time interval in which to play a sound. Second, I found out that playing the same sound several times in a row makes it sound like a typewriter or machine gun. Fortunately Mark knew how to fix this: create several variations of the sound and randomly pick a different one to play each time.

That leads me to something I learned about the process: always try out the sounds in the game. Sounds that sound great by themselves may not sound good in context, or when they’re interacting with other sounds. I unfortunately approved a couple of sounds that didn’t actually work well in the game. Fortunately Mark was nice and let me make changes even after I initially said they were OK.

The other thing I learned was that I needed to be as specific as possible when I wanted changes. It was easy to verbalize emotional reactions to sounds (I like this, I don’t like this, etc), but hard to spell out specifically how I wanted something changed, so Mark could actually do it. It turns out sound designers aren’t mind readers. Who knew?

After about a week of revisions, I had sound effects I was happy with. I paid IndieSFX, added their name to the about box, and checked the sounds into source control.

Using the sounds

During the creating process, I was taking the sounds Mark was sending to me and integrating them into my iPhone game. Since Mark was sending me uncompressed WAV files, I had to convert them before I could use them. Fortunately, Apple provides a nifty little command line tool to do just that: afconvert.

At first I was keeping the sounds uncompressed, for quality reasons, so I used afconvert like this:

/usr/bin/afconvert -f caff -d LEI16 <input WAV file> <output CAF file>

Unfortunately, high quality, uncompressed sounds are huge and this app is going to be distributed over the internet. So I switched to a compressed format, using this command line:

/usr/bin/afconvert -f caff -d 'ima4' <input WAV file> <output CAF file>

This gave me a 50% savings in size, with no discernible difference in quality. I chose these formats because I needed the sounds to be able to play simultaneously, and these are the two formats that the documentation say will allow that.

Lifting the veil

Hopefully this article has made the process of working with a sound designer more transparent. When I started this process, I had no idea what to expect — how much it would cost or how the process even worked. But I was quite pleasantly surprised. Getting custom sound effects created for an indie game is quite reasonable, both in time and money.

1. Customers hate paying for crappy applications.
2. Developers have a hard time getting exposure for their apps.
3. Developers want high enough prices to support development of their applications.

Identifying these as problems isn’t exactly a revelation, but I want to state them clearly. That way, when I examine potential solutions, I can see how well a given solution solves them.

Customers care about revenue, right?

A common solution that has been bandied about is the idea of changing the application ranking algorithm. Right now, applications are sorted based on how many people have bought it, which strongly favors the $0.99 applications. The “fix” is to rank applications by revenue. The logic is that by incorporating the price of an application into the ranking algorithm, it won’t be so biased towards $0.99 applications, and higher priced applications can flourish.

From what I’ve heard of this argument, it is attempting to fix both developer problems: non-$0.99 applications would get more exposure and applications can have higher price tags.

Unfortunately, this solutions fails the test for a number of reasons:

1. Sorting by revenue heavily favors large companies who produce blockbuster applications, such as Sega with Super Monkey Ball. Since they are well known, they can charge more and still sell a lot. This solution effectively squeezes out any small companies, or anyone with a niche application.

2. This solution only helps the top 100 revenue earners. Everybody else is still screwed. A solution that only fixes the problem for a small fraction of the developers isn’t really a solution.

3. Any ranking algorithm, no matter how complex, can be gamed. If an app is in the top 100, it makes an enormous amount of sales. That’s a lot of incentive to game the system.

4. The solution not only doesn’t address the customer’s concerns, it serves to confuse the customer more. What customer asks how much revenue a product generates, when deciding on a product of any kind? It is possible they might ask what the best selling one is, with the thought that it’s popular because it’s good or at least safe.

   Since this solution hurts the user experience, it’s pretty much DOA. Apple isn’t going to change the App Store to make it more difficult to use, even if it does help a few developers.

I think the proponents of this solution want it because it sounds like a quick fix that will at least shake up the top 100, and maybe give them a chance to squeeze into it. While I can sympathize with the desire to get more exposure, this solution doesn’t actually fix the problem and only serves to make things worse for users. But before I talk about another solution, I want to talk about the problem of getting exposure for an application.

Fixing the wrong problem

So the deal is the App Store can’t actually fix all three of the problems I mentioned. Specifically, it can’t fix developers not getting enough exposure for their applications. I know that Apple said they’d take care of all the marketing of iPhone applications when the store launched, but it’s time to face the fact that they can’t and won’t. Apple won’t feature all apps on the front page, and even if they tried, they could only do each one for a short amount of time. It’s simply not enough to bring in a sustainable stream of customers.

This has parallels in the real world. A store, such as Target, may advertise products it sells, but only certain ones and only for a certain amount of time. The manufacturer also must do some advertising in order for people to become aware of the product and actually buy it. This is true for all products, including the $0.99 a pack chewing gum that’s next to the checkout lane (the real world’s version of the top 100 apps).

Developers are too wrapped up in getting on the top 100 as a means for getting exposure. Everybody wants their product next to the check out lane, but the reality is only a few cheap, impulse buy type of products will ever make it there. All the other products are going to be out in the store aisles, where customers will have to be looking for them to find them.

The bottom line is that finding customers for your application isn’t a technical problem, and a technical solution isn’t going to fix it. It is a marketing problem, and it requires marketing to fix it. Since developers can’t count on Apple doing the marketing, they need to do it themselves. I know that’s scary news to those of us who have only ever been engineers, but we need to acknowledge it and work through it.

Taking a test drive

Now that we’ve learned that getting exposure for an application isn’t a problem the App Store can fix, I want to focus on the remaining problems it can fix. Another solution that has been proposed is the now ubiquitous (on the desktop) try-before-you-buy model. The idea is simple: a potential customer can download an application for free and use it for a set amount of time, say 30 days. At the end of the 30 days, the potential customer can either buy it or it’s deleted from their phone.

This solution, while more complicated than the ranking solution, actually solves the problems:

1. Because the customer gets to try out the application before buying it, they don’t have to worry about paying for a crummy application that doesn’t solve their problem.

2. Since customers can try out more expensive apps without risk, they are more likely to buy the more expensive application, since they can figure out if it’s worth the price or not. This allows more expensive apps to survive in the App Store.

As an added bonus, the top 100 becomes more accurate because only the apps that users actually think are worth something increase in rank, instead of apps that had the best screenshots or descriptions.

The thing to remember is that the App Store is still young and still maturing. While it is different from other markets, it’s not that different from the desktop market or the other mobile markets. People still want to try out applications before they buy them, and developers still need market their products if they want someone other than their mother to know about them.

The Parable of Little Timmy

Little Timmy was a developer at BigCoSoft, but he dreamed of working for himself one day with a product of his very own. When the iPhone SDK came out, he set aside all his free time and slaved over a new iPhone application for months.

When it came to pricing his software, he decided to sell it for the lowest possible price, $0.99, because that’s what everyone else was doing and besides he’d make it all up in volume, whatever that meant. Plus, he already had 12 year old boys yelling at him because the software wasn’t free, and he’d hate to upset anyone.

Unfortunately Little Timmy couldn’t live on $4,000 a year, so he died. BigCoSoft cremated his body in their furnace so they could save $14.67 on their heating bill.

The End.

I realize that some of my readers are engineers, and prefer cold hard facts. So for you my friend, some math problems:

Question 1:	Assume Little Timmy could live off of $50,000/year, before taxes (Note: this means you have to assume Timmy doesn’t live in California, New York, or any big city, but in a farmer’s wheat field in some desolate corner of Iowa.) How many copies of his product would Little Timmy need to sell to eat?
Answer:	Since Little Timmy only priced his software at $0.99 and Apple takes 30%, Timmy only makes about $0.70 per copy. He would need to sell 71,428 copies a year or 196 copies a day.

Question 2:	How many copies a day should Timmy expect to sell, after the initial launch?
Answer:	16

Question 3:	Isn’t Little Timmy just about the biggest moron you’ve ever heard of?
Answer:	haha! Yes!

So now that we’ve finished mocking poor Timmy’s corpse, we should talk about how to price your application before you become firewood.

The Problem

The problem that you’re likely to have, like most developers, is setting a price that you can live on. The temptation will be to price your app too low, such that developing the application isn’t sustainable. You might have the best of intentions, but in the end you’ll cause the premature death of your business before it even gets a chance.

So why might you be tempted to price your iPhone application so low?

Reason #1: Initial store prices

A lot of people were looking at the apps announced at WWDC to see what they would be priced at. In particular Sega’s Super Monkey Ball, priced at $9.99, seemed to receive the most attention. Developers releasing around the App Store launch seemed to use Super Monkey Ball as a barometer as to how to price their app. Unfortunately, most of them seemed to think they needed to beat Sega’s price.

Here’s the thing: engaging Sega in a price war is a sure fire loss. They’re a bigger company with deep pockets and will always be able to undercut you in price. They don’t need make much, if any, profit on their iPhone game, since they have a lot of other products. You, on the other hand, need to make a profit on your iPhone app, and a big enough one to live off of.

Reason #2: Customer expectations

Sega’s initial pricing, and the subsequent following suit of just about everyone else, set customer expectations for iPhone app prices. Developers entering the market in the following months felt compelled to follow the example of the first developers. These feelings were only reinforced by just about every “customer survey” done by TUAW and other bloggers, in which potential “customers” said they wouldn’t ever pay more than $5 for an iPhone application, although they really didn’t understand why those greedy developers felt they needed to charge anything. After all, they could make it up volume.

Unfortunately the blame for setting customer expectations falls squarely on developers. Developers get to set the price, and thus the expectations. By setting the price expectations so low, you are lying to your customers. You are saying “I can sustain development of this app for this price,” when in fact, you can’t. It’s dishonest, and it will kill your business.

Reason #3: Gaming the system

By far the biggest reason why developers price their apps so low is to game the App Store. Applications are sorted by how many copies they have sold. It doesn’t take a rocket scientist to figure out that the lower the price, the more copies an app will sell. The top 100 applications sell tons of copies, while applications outside that top 100 seem to wither away unnoticed. So in order to get more exposure, developers price their applications as low as they can.

The problem is that this scheme only supports 100 applications. Everyone else is hosed. Unless you can get and stay in the top 100, then lowering your price was for nothing.

It is likely that Apple will fix this hole. They want to make money too. For a $0.99 app, Apple is only making $0.30 per copy, which has to cover bandwidth, transaction fees, and advertising. I’m not suggesting Apple isn’t making money off $0.99 apps, but I am saying they’d probably prefer to be selling $9.99 apps.

Reason #4: Short term vision

The App Store is quite young and with all the hype and exposure a few of the first developers struck it rich. This isn’t unexpected for some of the pioneers, but the problem has became that many developers enter the iPhone app market thinking that they too can become fabulously wealthy, just as soon as they release their flashlight app that also doubles as tip calculator.

The problem here is that developers become focused on making money now, instead of nurturing and building up a loyal customer base over the long term. They price their app low so they sell a lot of copies now, but don’t consider how they’re going to make money next year. What is the upgrade price that you charge for a $0.99 app? If it’s $0.99 then you’re not building customer loyalty because that’s not a discount. If it’s free, then you’re totally screwed, because you’re not making any money.

The Solution: $9.99 is the new $0.99

The fix for pricing too low is really simple: raise your prices. Most $0.99 apps should become $9.99, $4.99 apps should become $14.99, and so on. With a $9.99 app, you’d make $7 per copy and at 16 copies per day, you’d make about $40,000/year. That’s not a great income, but that could potentially support one iPhone product being developed in some Iowan’s wheat field.

Without question there will be customer backlash when developers increase their prices. Nobody likes paying more for something. However, the sooner the righting of the ship happens, the better. Customers need to know that most applications can’t be built and supported for such a small amount of money.

On the other side of the equation, developers aren’t going to be eager to be the first to raise their prices. So many are convinced that they won’t sell anything if they raise their prices. Here are some of the potential concerns:

Myth #1: No one will find my app!

This goes back to developers gaming the system. If a developer raises their price, they will sell fewer copies and drop off the top 100, which means no potential customers will find them. There are two possible solutions to this problem.

The first is Apple could fix it so applications that are not on the top 100 are easier to find. It may take a while for Apple to implement this, but eventually Apple will because it’s in their best interest. When this happens it won’t matter what the price of the app is, people will be able to find it.

The second possible solution is to do advertising for the application. This will take some trail and error to figure out where to buy ads at or which adwords to buy, but it can definitely be made to work. Advertising is hard for $0.99 applications, because if you spend more than $0.70 per conversion, then you’ve lost money. In other words, if you charge more you can make sure more people see your app.

Myth #2: But those other people sell it for less!

Competing with another application solely on price is a sure fire way to go out of business. Your product should have a selling point other than the price, whether it be more features, better usability, a unique approach to the problem or all of the above.

There will always be students and hobbyists in the market who can sell a competing product for way less than you. They don’t need to make a living off the app, so they’re not trying to. This happens all the time in the Mac market. If you charge enough for your app that you can make living off it, then you can spend all your time improving it. With that extra time you should be able to make a superior product to your lower priced competitors.

People are willing to pay more for superior products. Unfortunately, with the App Store developers haven’t given them the opportunity to do so.

Myth #3: This is the price the market will bear

Another way to say this is: the price of application is what the market is willing to pay.
I don’t dispute this, but there is another side to this equation.

You also need to consider what the price of building and supporting the application is. If the cost of building the app is greater than what the market is willing to pay, then simply don’t build the app because it will be a failure. Building the application regardless is dishonest to the customer, because you’re in effect selling them what you know will be abandonware.

I also contend that, in general, developers don’t know what the market will bear because no one’s really pushed the price. Everyone is currently in a race to the bottom. The App Store is still in it’s infancy, so no one’s had time to tell if raising prices actually kills the application, or if it just means it takes longer for it to take off.

Myth #4: I can make it up in volume!

I’m astounded at the number of developers who believe that this is true. While it is true that some developers have made a lot of money this way, this isn’t sustainable or practical for most applications. In order to make up for the low price in quantity your product needs to have mass appeal. Furthermore, your potential customers have to be able to find your product, which means you have to be in the top 100 and have Apple feature your product in their advertisements. In other words, you’re betting a lot of this on luck, and the odds are stacked against you. You’d have better odds playing slots at a casino.

Judgement Day

The App Store can’t stay at the status quo. There are three possible outcomes:

1. The App Store becomes a market place solely for hobbyists and students, who can price their wares low because they don’t need to make a living off of them. In this scenario, indie developers aren’t in the market anymore and there is only the occasional BigCoSoft game port.

   Eventually this market would become littered with abandonware as hobbyists and students moved on to other projects that actually pay. The occasional BigCoSoft game would keep the iPhone as a second rate gaming platform.

2. The App Store becomes a market for one off apps and abandonware, where apps don’t progress beyond version 1.0 because there’s no money in it. Apps are simple and cheap to build, and developers rely on the initial sales spike to make all their money.

   The store would become so littered with dead apps that falling off the top 100 would be even more fatal. Eventually the store would die as developers ran out of simple app ideas that would generate a sales spike.

3. Developers begin pricing their products in a way that is sustainable. Developers who price too low eventually die off, unable to develop their products further. In this market, prices go up, which encourages indies and BigCoSoft to build and release many apps and games for the iPhone.

There will be an iPhone app bust. The current prices simply aren’t sustainable. Either developers will crash out of the market when they discover they can’t make a living off their current prices, or the gold rush developers will lose interest and leave when they realize they can’t make a quick buck off the store. The developers left standing will be the ones who set reasonable prices for their applications.

I’m willing to put my money where my mouth is. I currently have an iPhone app in development, and when it comes out, I will price it $9.99 or higher. I’ll let you know how it goes for me.