Mobile App Monetization Planning

We are living in a unique time. Smartphone and tablet sales are continuing to rise as desktop and even laptop sales are beginning to surge downwards. consumers are continuing to plug into the information age anytime and anywhere, which is creating a unique paradigm shift poses some unique problems for those of us attempting to make some real money with our software products. In June, Garner research group released a report stating that:

Worldwide traditional PC (desk-based and notebook) shipments are forecast to total 305 million units in 2013, a 10.6 percent decline from 2012 , while the PC market including ultramobiles is forecast to decline 7.3 percent in 2013 (see Table 1). Tablet shipments are expected to grow 67.9 percent, with shipments reaching 202 million units, while the mobile phone market will grow 4.3 percent, with volume of more than 1.8 billion units. The sharp decline in PC sales recorded in the first quarter was the result in a change in preferences in consumers’ wants and needs, but also an adjustment in the channel to make room for new products hitting the market in the second half of 2013.

“Consumers want anytime-anywhere computing that allows them to consume and create content with ease, but also share and access that content from a different portfolio of products. Mobility is paramount in both mature and emerging markets,” said Carolina Milanesi, research vice president at Gartner.

Table 1

Worldwide Devices Shipments by Segment (Thousands of Units)

Device Type




PC (Desk-Based and Notebook)












Mobile Phone









With mobile usage on such an increase, appropriate platform focus is becoming even harder. The trade off of creating mobile first products, whether that be iOS or Android apps or mobile friendly websites, with a higher price tag paid solution is becoming harder to achieve.  However it’s clear that the mobile movement cannot be ignored.  The trouble is finding ways to harness the power of mobile usage while at the same time finding reliable methods to monetize these applications.

Traditional web based SAAS or one time purchase apps have their merits in both scope of functionality and in pricing potential. With app stores, there is a limit to expected pricing level, pricing structure, and even overhead (when considering the 30% cut that Apple takes). Desktop based web services sure do offer a potential increase in fucntionality as well. There’s only so much that can fit on a 4″ iPhone screen, even if you’re the best designer out there. A 21″ LCD monitor can just fit a lot more real estate than we can achieve in a desktop based app. Add to that internet connection speed, media resolution, and overall media richness, and in an ideal world we would all create desktop solutions. And maybe we should, just for the dollars and cents of it.

There are several high profile app-centric developer shops that have thrown up their hands and proclaimed that paid apps are all but dead. Where does this leave developers who are looking to share in the mobile movement that we’re experiencing? Well to me there are a few options:

1. In-app purchases via native apps
2. Free native clients with a paid backend web service
3. Responsive designed web apps that are truly mobile first
4. Build free native apps with the eye on selling soon!
5. Free native apps with ad revenue

There’s a lot to each of these, so we’re going to split up the analysis over 2 posts, but for now, let’s look at each of these in a little detail for their intrinsic tradeoffs.

In-app purchases

Apple and Google’s In App Purchase program was a windfall for some developers who have traditionally made free apps and hoped to make their money on advertisements or in selling off the entire product. This allows for app users to purchase within an app additional functionality. Typical examples of this are things like extra lives in a game, access to unique features not available to standard users, etc. This allowed developers to start creating apps with the In App purchase in mind…keeping a few nuggets away from the original user, with that upsell in mind for a later time.

The downside of the In-App purchase are numerous, however. Apple  does restrict the types of things that can be sold under the IAP program. For instance, you can’t sell a different functionality, just more of the same.

At Apple, there are four supported categories of In-App Purchase items that you may sell:

  • Content
  • Functionality
  • Services
  • Subscriptions

Items from the supported categories must fall within one of the following purchase types:

  • Consumables
  • Non-Consumables
  • Auto-Renewable Subscriptions
  • Free Subscriptions
  • Non-Renewing Subscriptions

There are a handful of important guidelines to keep in mind as you design your application:

  • You must deliver your digital good or service within your app. Do not use In-App Purchase to sell real-world goods and services.
  • You must make your In-App Purchase items available to all of the devices registered to a user.
  • You may sell credits or virtual currency provided they are used within the app and do not have a time limit imposed upon them.
  • Items you offer for purchase may not contain, or relate to, pornography, hate speech, defamation, or gambling (simulated gambling is acceptable).
  • In-App Purchase items cannot be shared across applications.

The benefits here, however, are that you can release something to the masses that they can get for free, and then “upgrade” at a later time.  For apps with huge download volumes and an design that accommodates IAP well, this can be a sure fire way to make big bucks.  However, this can also flop pretty quickly if there’s a truly free way to for users to achieve the same, or similar results from a competitive product.  This is the closest that you can get with native apps to a “freemium” model.  However, if you’re intent on building a true software company, not just a one hit wonder or an app you build on nights and weekends, then hoping for an app to take off AND the In App Purchase rate to be through the roof probably isn’t the best bet for most of us.

I would save an IAP based moetization scheme for an app that creates custom content and I want to create a subscription based service through my app.  Not only do I LOVE the idea of recurring revenue, I also like giving some users unique content that isn’t available to everyone.  The one other place I can see this working out really well is adding in a few pieces of functionality to an app that are difficult to create (or replicate by a competitor), and would need to be worth my time in development.

Mobile analytics company Flurry reported in 2011 that the vast majority of top-grossing iPad and iPhone apps (75 to 80 percent) featured in-app purchases.  As I always tell my wife:  ”everyone’s not usually wrong”, and this may be the case here.  In an era when paid apps simply aren’t as much of an option as they once were, going to alternative monetization strategies is essential.  Assuming you can fit IAP in with your app’s functionality and model, I would go for it.  This seems to be the sure fire way to go within native apps.

Free native apps with paid web services

This might be bordering on the edge of legality within Apple and Google’s app programs. Each program states that “You must deliver your digital good or service within your app”.  However, the benefit here is that you could get the best of both worlds. You could have the mass adoption of your app on the growing platform of these mobile products, while at the same time realize some recurring revenue (or at least solid one time pricing) of a web based service. Whether this can actually be done in your instance may be up for debate.

One instance of this definitely succeeded with “Remember The Milk“, a popular web and native app that charged for it’s services via the website for increased functionality.  I believe this model was successful because it did not change the underlying function of the iOS app, but rather added to a web based technology.  This may get shot down from the approval committees at Apple and Google, however, so a backup plan or modification may be needed if that’s the case.

I would use this model just like Remember The Milk did.  If I had an app that already had networked functionality, I would beef up that functionality somehow, maybe with Geotracking, advanced syncing, or other custom features.  Build this added functionality into a web portal that talks into already existing app features, and there’s not much that Apple or Google can say about it.

A Wrap For Now

Here’s a quick read on the new app called Applause, which is mobile ticketing app.  Apparently the folks over at Applause are creating quite a stir in the ‘app commerce’ arena.  Making a quick, useful, and meaningful impression on users is more important than ever.  There are hundreds of thousands of apps out there, and to differentiate yourself now, not only does your app have to work well, but the UX has to be astonishing.  Check out this article on how the folks at Applause are doing it like no other:  Applause and the New App-Commerce.

I’m going to leave it at these two options for today.  More to come next week on the remaining options for app monetization.  Until then if you have things that are working really well for you I’d love to hear about them.  Thanks for tuning in.

Related Posts:


Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>