This is a beginner's guide to monetizing your iPhone App. Writing this article has helped me clarify my thinking, and hopefully it will stimulate you with ideas that you will share so that we all benefit.
Developers used to just simply charge for software. You would write a program that others considered valuable and they would pay for a license to use it. Developers also used to charge for updates. Those same people who bought the original product would pay periodically when you added significant features and improved the product's operation.
Software sales are not so simple anymore. There is a definite a downward pressure on app prices; many users even expect them to be free. Of course, “There is no such thing as a free lunch” (TANSTAAFL) so somebody, somewhere, is going to have to pay at sometime. If not, app development will not be economically feasible and apps will be abandoned. However, perhaps we should at least consider that a large part of the industry is moving away from the pay-full-price-up-front model.
In this post I list several approaches to monetizing an iOS app. Many of these approaches are also valid for Android, Windows Phone 7 and WebOS, but I am most familiar with the Apple iOS iTunes App Store ecosystem. I address only the native mobile device applications because web sites and services have their own challenges.
There are many variables involved. The approaches below do not represent exclusive categories, but rather common approaches that I felt were important to highlight. Thus, the boundaries are fuzzy and the approaches may overlap.
Most people have a favorite approach; my hope is that this list makes you think and you consider alternative approaches you could adopt.
By the way, the apps I list below are linked through an affiliate link to the app store. If you click them and end up buying something it won't cost you anything extra and I'll get a very small percentage commission. You can't blame me for trying to cover my coffee habit and it happens to also be a use of one of the approaches listed below. Please also be aware that, although I use many of the apps mentioned, they are not meant primarily to be recommendations but rather illustrative examples of the monetization approach being discussed.
You could build and publish an app and not charge for it nor ask directly for money in any way. Sometimes people do this because they want to share something with the world and though some of these apps will continue to be updated and improved over time this is generally not an economically feasible model. Providing an app completely free can make sense, however, if you are using it as some kind of branding or promotional device for another product or service. For example, if you are starting out as a developer it can be useful to have an app in the store to promote your consulting services (bear in mind that you'll get judged more on graphics than programming ability or even usability, so make sure the icon is attractive and get a graphic artist to help with the UI). If you are a large corporation (egs, Starbucks ) a free app can also help to promote brand awareness and customer loyalty. Sometimes the free app is is a lite version used to promote a paid app ( Fruit Ninja Free ). Also It is possible that an app can start out free and end up switching to paid later ( Fruit Ninja ) Pros: You can't beat free. Customer acquisition costs are very low. Cons: You not making any money. People may give bad reviews to feel better about themselves. If there is a cost involved for you (ie. server or support expenses), each customer may end up costing you money.
Many free apps are actually ad-supported. That is, they don't cost the user anything to install, but the user is periodically shown an ad that the developer (publisher) is paid for ( reMovem (free) - Mundue LLC ). Of course, an ad-supported lite version of an app can serve to promote a paid version, another service or product. Popular ad networks include iAd AdMob and a service like AdWhirl can help you manage multiple ad networks. Pros: The more customers you generate to use your app the more you can make from ads. Cons: May need many users to make a decent amount of revenue. Ads may not fit well with the spirit of the app.
I have not seen many sponsorship supported apps in the App store (let me know if you have) but I have spoken to clients about this approach. The idea is very similar to ad-supported, but instead of going with an intermediary ad network, you sell your own sponsorships and have more control over ad topic, kind, size, placement and frequency. I feel this would work well in apps based around a hobby or special interest. For example, one might develop a film festival app and get sponsors for each film festival, such as the festival promoters or businesses near the festival. A related approach would be to white label the app so each festival could have the prestige of having their own app. Pros: More control. Better targeted ads. Larger sponsorship fees. Cons: More work to sell sponsorships.
Another related approach is an affiliate sales relationship where a third party pays the developer each time they bring a user to the third party product or service. For example, hotels lose money on empty hotel rooms so they discount empty rooms each day, and there are marketplaces available to facilitate with these transaction. One could write an app to help travelers find last minute hotel rooms at a discounted price. The app would not only be free but would save the user money and would not require ads as the hotel would pay the developer an affiliate fee via the marketplace. This same model could also work for sporting and musical event tickets, as well as app review recommendation apps. Pro: Unlimited potential for a successful app. Cons: No control of the commission. Marketplace may have competing app.
The rest of the apps are paid for by the consumer rather than a third party. I want to first mention the mass market lower price approach. These often come in the form of games, novelty apps, and small utilities, etc. (eg. Angry Birds - Rovio Entertainment Ltd and many others). The key idea is that a historically low price is made up for by the volume of these large audiences. Pros: Huge audience for this type of app. Cons: Needs to be a hit. Lots of competition from other apps.
If you app does not have general mass market appeal it can still find a home in a niche market. A niche app might have a smaller market but by providing unique and compelling value can sell at a much higher price than a mass market app. Examples include iTeleport Remote Desktop - VNC & RDP - iTeleport Inc. $24.99, OmniGraffle - The Omni Group $49.99, BarMax CA - BarMax LLC. Pros: Classic model. Cons: Downward price pressure. Needs a clear and compelling value proposition.
Using the In App Purchase (IAP) mechanism for free apps was approved in Oct 2009. Using it as an upgrade mechanism has had mixed success. The basic approach is to provide a fully functioning useful app (an Apple requirement) that is still somehow limited and then provide an IAP as an upgrade path to add additional functionality to the app. This is the approach I use in my app iCardSort - E-String Technologies Inc. ; it is similar to providing a lite and a paid version in one application and simplifies the user's data management when they upgrade. Pros: Lets users try before they buy. No data transfer issues when upgrading. Multiple upgrade options can be made available. Cons: Users complain app is not really free.
IAP can also be used to provide in app virtual (consumable) goods such as fertilizer for your farm, bullets, special powers, additional costumes and customizations for your characters etc. Games such as Candy Crush Saga - King.com Limited and Flower Garden - Grow Flowers and Send Bouquets - Snappy Touch are common examples of this. This works really really well if it is acceptable for your app's genre. While becoming more common in games, the use of IAP consumables has been limited in business and utility apps. Also, there has been negative press lately about kids buying items without understanding the real life implications of spending money. Pros: Excellent potentials Cons: Bad press from users who don't understand purchasing implications.
Using IAP subscriptions to provide content has been big in the news lately. The classic examples are magazines and newspapers such as the The Magazine. - Aperiodical LLC Public acceptance of this model still remains to be seen. However, I believe it is reasonable and fair to extend subscriptions to services as well as content. For example, I love the Instapaper - Instapaper, LLC as it is a very valuable app that I use frequently. Because of this, I would be willing to pay more than the current one time price ($4.99), especially since the developer will have recurring server costs associated with my use of the app. IAP subscriptions for content are still not fully accepted, and I don't know if IAP subscriptions for services will be a success in the long run, but it is interesting to think about.
Hope you found this useful and that you've begun thinking about your current approach and possible future options as the markets change. My personal interests lean towards small audience niche apps (that unfortunately don't yet sell well), so my feeling is that IAP upgrade gives me the best chance to build sustainable products. If I were a cool game developer, however, I would do everything I could to implement IAP consumables. We'll have to wait and see if IAP subscriptions take off for periodic media, applications and services. I'm sure we all have different opinions and these categories could be presented in many different ways. If there is something I left out, or if you want to share your thoughts, I would love to hear from you. Let me know which approach you feel is most viable for you. Also, if you have experience with one of these approaches, I would love to hear your story. In particular I would like to know:
Thanks for your input.