Tag Archives: apps

No, In-App-Purchases are not a good alternative to paid upgrades

Posted by on July 27, 2012 No comments

Recently, there has been a lot of discussion about making app development more sustainable – these discussions were intensified by Sparrow’s acquisition by Google last week. This acquisition was bad for users, since it meant there would be no further development on the Sparrow Mail app. One theory being floated is that if app development were more sustainably profitable, fewer teams would be tempted to sell in situations that would harm the long-term future of the app.

One idea for improving the long-term profitability of an app – and thus the amount of effort that goes into continually improving it and adding new features – has been the idea of upgrades. On HackerNews and other forums, however, many folks have claimed that such an option already exists – “upgrades” via the In-App-Purchase (IAP) functionality that exists on all stores today. I wanted to share why I think this is a really poor approach – for both the user and the app developer – and why upgrades are a good way to financially motivate developers to deliver useful, significant upgrades to their existing applications.

The Idea

Proponents of IAP as an upgrade argue that developers should continue to develop the core of an application and sell new features as IAP items. The argument is that users only pay when they derive new value from the application, and only purchase the functionality they want. Admittedly, there is probably some subset of users who would enjoy customizing their software to the max and saving a few bucks in the process, but I think the vast majority of users would find this to be a nuisance.

Nickel-And-Dime Your Users

The main problem with IAP-as-an-upgrade is the fact that your users are going to feel like they are getting nickel-and-dimed to death. Imagine this scenario: You see someone using a cool app and think “Hey, that would be useful to me!” You purchase the app, only to find that it only does about half the things you saw the other person’s app doing – to get the same functionality they had, you are forced to purchase a bunch of “upgrades”, possibly doubling the price of the app in the process. This is not going to delight your users – it will instead confuse them as they try to figure out what combination of features they need to purchase to actually use your app in a way that is meaningful to them.

The other problem with this approach is that it misses on benefit of paid upgrades – usually, the upgrade price is less than the full price, as a reward to your existing customers. This can’t be accomplished with IAP.

Create headaches for yourself

IAP-as-an-upgrade also creates headaches for developers. Improvements to your application can come in many forms – new functionality, improving existing functionality, performance improvements, UI improvements, and more. Rarely do you come up with a single feature that is worth paying for by itself. This approach forces you to think about it in terms of individually sellable items, which can get really complicated when there are feature dependencies. It encourages you to to focus on discrete functionality that can be sold, rather than potentially big general improvements to the application. Some proponents have even suggested including multiple code bases – even if Apple or the other app store maintainers would allow this, I cringe at thinking how ugly of a solution this is.

Upgrades are a good feature

Upgrades have a lot of advantages:
 

  • They align your interests with those of your users – Users want applications they depend on to be maintained and improved for long periods of time, and you want the ability to derive a stable long-term income from that work.
  • By making the upgrade price less than the full price, you reward your existing users.
  • Application-specific settings are maintained in the event of an upgrade.
  • Users don’t end up with a mess of different versions of your application, as happens when developers decide to simply sell a new product as a new version.
  • Upgrades are a simple, well-understood system for delivering new versions of software.

Drawbacks

The main problem with upgrades are transaction fees. It would be expected that an upgrade would cost some fraction of the original price of the application, but with many applications charging $0.99, this doesn’t give a lot of room for discounting – Apple’s fixed cost to run a transaction is rumored to be in the neighborhood of $0.15, which doesn’t leave a lot of profit for them at levels below $0.99 with a 30% cut of the retail price. I think there are a few ways to deal with this:
 

  • $0.99 app upgrades could be discounted less – say, the minimum cost of the upgrade is $0.75.
  • Only apps $1.99 and up are eligible for upgrades.
  • Apple takes a bigger cut of upgrade fees.

IAP is a great feature and is useful in a lot of scenarios, but it doesn’t obviate the need for upgrade functionality. As a user and a (really small-time) app developer, I hope app store maintainers seriously consider offering upgrade functionality in the future, and I hope even more that we don’t see a bunch of developers trying to implement them as IAPs.

Ad supported vs $.99 – My experience

Posted by on September 11, 2011 1 comment

I love football, and I can’t tell you how excited I am that it is back on this week. I love playing fantasy football even more, and have even made an iPhone app for fantasy football drafts the past few years.

This isn’t my day job, and I know I’ll never get rich doing it. My main goals are to get some more experience developing for iOS, earn back my expenses, and help pay for NFL Sunday Ticket.

Last year, my app was sold for $.99, and I made a small, but reasonable amount of money (something between $400-$500). This year, I decided to see what the results would be like if I offered it for free, but monetized it using advertising. At the last minute, I decided to make another version that cost $.99, but was identical except for the fact that it lacked ads – ads are sometimes kind of annoying, and as a user I’ll often opt to pay $.99 rather than deal with them.

Now that the fantasy football draft season is over, I thought it would be kind of interesting to take a look at the results. The limited shelf-life of this app (drafting season is at most 2 months long, and the average user won’t use it more than a few hours per year) makes a less than ideal case study for ad-supported vs paid, but I think there is some interesting data anyway. So, here is some stuff I learned from this:

1) Free apps get downloaded way, way more than even $.99 apps

This is obvious, of course, but the magnitude of the difference is worth pointing out. The free version of my app was downloaded 11,450 times, whereas the $.99 version was downloaded only 239 times.

My takeaway from this is, if you’re going to try to sell an app that is going to have free competitors, you’re really going to have to work hard to differentiate yourself from the free versions. Free apps are simply going to eat up the lion’s share of the market.

2) But they don’t make nearly as much, per-user

Those 11,450 downloads translated into several hundred thousand ad views, resulting in total revenue of $111.25 for me. This is very slightly less than $.01 per download. The paid version brought in $167.34 from its 239 downloads – despite having roughly 1/50th of the downloads, it actually out-earned the ad-supported version by ~$55.

I almost certainly made a lot less money this year by offering a free version supported by ads – if even 2% of the users who downloaded my free version would have shelled out $.99 for the paid version had it been the only option, I would have come out ahead.

Had this app been something people would use year-round, it might have worked out a little better.

Lessons for next time

Despite this not being the ideal outcome, I learned a few lessons from this. Your app has to be immensely popular to make any sort of worthwhile revenue from advertising. I don’t think niche apps or apps with limited lifespans are good candidates for ad-supported versions. Also, I think there are probably better ways to utilize a free app than just throwing ads on it.

Probably the best use of an ad-supported app is to use it to promote additional, paid functionality. You could do this through In-App Purchase or by selling a different version of the app altogehter. The important thing is to differentiate the two beyond just advertising – the paid version should also offer more features. I would have done something like this, but I given the short life-span of these apps and my late decision to offer both versions, I didn’t have time.

Going this route gives you a chance to use your likely more popular free download as an opportunity to promote the paid functionality. Just be careful to offer enough functionality in the free version to make it worth downloading – free apps that are utterly useless platforms to promote paid functionality get (rightly) harsh reviews in the app store.