For What it’s Worth, My 2¢ on In-App Purchase

Letting users know your app is worth more than $0.99


Disclaimer: Lightly revised, and hardly edited, so hopefully you’ll focus on the big picture, rather than my Oxford commas and Stanford semicolons😉


How much would you pay for an apartment that you’d never set foot in versus one with a walk through?

How many paid-apps do you see on the store that are $0.99?

$0.99 has become the elastic waistband jeans of pricing. One size fits all. It’s tough to get a customer to commit to anything more for an app that they’ve never touched, tested, or tasted. Who would pay more for mystery meat?

The chicken fried steaks at the cafeteria were great some days at the cafeteria, but other times… 😰

I’d been part of the mystery meat crowd for some time. I released our team’s app Look Up for $0.99, and was happy to get good downloads and hit the top 10 and be the number 1 health app for a few days. I was happy, and even more thrilled when enough users said they would have happily paid $5, $10, or more for if they could have tried it first. This got me curious, so I started doing some research.

I started taking in-app purchases (IAP) more seriously, as they seemed to be the best way to get rid of the mystery meat problem. In researching, I read a few blogs on apps that switched to IAP models, and despite the hype on IAP’s they were let down. Downloads went up, but revenue went down.

Their findings let me stick to my stance and continue to use a regular purchase model, pre-download. After all, IAP’s require significant dev time, while no development is necessary to sell an app the traditional way. I was more than happy to stick to my ways.

The problem with many post-transition comparisons, is most apps are keeping the same cheap elastic waistband pricing that they used for their mystery app, despite taking away the negative side of the mystery. An IAP based app provides value to the customer in a seamless trial. It also does cost more development time too.

More important than the additional dev time though, is how it gives you the resources to extend your dev time. IAP’s give you more time to spend on the details, that you’ll have to polish since purchasers can touch and test your app before purchasing, because of the support they give for a raised price. If you’ve put your work in polishing, your additional dev time shouldn’t double, but can be covered by even the smallest increase in price. After all, your app can at least now justify the smallest possible increase in price… double ($1.99), triple ($2.99), or multiples of the original price.

The thing is when an app is based on an in-app purchase the customer can perform some form of a smell test, possibly a taste test, or even full on test-lease depending on the purchase model.

This means the mystery meat pricing can and should go!

This means your price can go up and your customers will actually thank you for it. This does not mean anti-customer purchasing models that don’t let a customer take ownership of your app pre-purchase. (Some thoughts on the good and bad of that performed by Amazon’s Kindle here)

Sure an in-app purchase model may mean less total sales, but I don’t need to tell you what that smaller amount of sales can mean.


If you want to see how we’ve handled our IAP’s on iPhone with SnoozeCast or Mac in Rough Draft please do! They’re by no means perfect, like this rough draft, but might provide a good base.

p.s. This post was written in Rough Draft, sorry I didn’t have time to revise it just yet! Please ask questions, point out the bugs/errors, and help me to improve it! 🙏

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.