App Store Payment Models

by 2nd March, 2017

When looking at how to monetise your product you first need to decide whether it is a revenue earning product or an investment product. If you see your app as a steady stream of income then you are looking at a revenue product. If, on the other hand, your app relies on sheer numbers of people such as a social network, the it is more sensible to give the app away for free and seek to build value in both the platform and the user base; in this instance you have an investment product. If you are in the latter category then pricing models don’t make any difference to you, if you are in the former, however, they can mean the difference between sink or swim.

Single Payment (SP)

This is the most traditional payment model and works on the concept that people pay a single fee to download your app. Users are not able to even download the app without payment and so this is often combined with a free version of the product with a limited feature set.

This model is often stated as currently transitioning to being an unviable payment model however it is still one of the most effective. If you produce a great product and can demonstrate that with the screenshots, app copy, videos and other marketing efforts, you can make significant revenue using this approach and it is the most straightforward one to utilise. Unlike in-app purchase or ad-supported models, you don’t need to change anything within the app itself, no integrating ad frameworks or setting up in-app purchase options.

Free With Unlock (FWU)

This model combines the paid with free version model above and creates a single limited product for free download whereby users can make a single (or sometimes multiple) in-app purchase to unlock the extended features. This model is one of the most commonly used models and is a way in which you can create a single product without the need for both a free and paid version as in the SP model.

The downside is that you need to create a new version of your product and decide which features are free and which will be paid for. The main sticking point with this is that you cannot leave any visual clues as to the paid features in place without incurring the wrath of Apple inspectors. You CAN upsell within your app, advertising the features however you will need to remove any non-functioning buttons and elements from the free version before submission. This leads to a confusing experience for your users and also makes you life more difficult when trying to decide what features should be free or paid in the first place.

Pay To Play (PTP)

Most commonly found in games, and sometimes combined with all of the other models listed here, the PTP model allows you to use the product but at a reduced rate, normally there will be some kind of value in the product which depletes during activity, you can wait for this to recharge over a period of time or pay to recharge immediately and continue playing.

As mentioned, this is most widely used in games such as CSR Racing whereby you expend fuel each time you race. The fuel automatically refills over a long period of time however those of us who are impatient can make a payment to continue playing immediately. This model can lead to large amounts of revenue as it is a recurring payment and not a single one-off. The downside to this model is the negative connotation that comes with it especially for those apps that also charge a one-off fee as per the SP model. You will also need to work out a suitable mechanic for the refill so as not to fall into the Pay To Win category (below).

Pay To Win (PTW)

This is a slightly darker variation on the PTP model however with PTW it isn’t feasible to advance through the game without making a payment. To comply with Apples rules it IS technically possible but the chances of you doing so are so low that you can consider it impossible. This type of model should be excluded from your thinking otherwise your brand will suffer a negative backlash from an app which appears unfair to your customers.

Ad-supported (AS)

This model works on the basis of providing the app for free and deriving revenues from showing targeted ads for which the developer will receive a payment for showing. The AS model is regularly used in conjunction with the FWU model to allow users to make a single payment to remove the advertising. Whilst it is possible to generate decent revenues from advertising (if you have a LARGE daily session count), it is also one you should exclude for a number of key factors. The main issue with AS models is that you have to integrate with a third party framework in order to deliver the ads, unless of course you are building your own proprietary ad platform in conjunction with your app (but you’re probably not!).

When you integrate ads into your product you compromise the visual experience for your user. You can spend a large amount of money on your branding only to ruin the aesthetics of your app by giving up a valuable chunk of the screen for a third party to place content into. Without ANY control of the content they deliver, the results can be disastrous. If you are looking for decent revenues AND a decent experience then you need to stay away from advertising. There are more modern ad networks, or ad reward networks, which take a slightly different tack on advertising however the traditional ad networks should be avoided to ensure you maintain control over the aesthetics of your product.

Donation ware (DW)

This model is rarely used but is the model by which you offer your product free to your users and ask them for a voluntary donation for using it. Usually they can set the amount they wish to pay, however this is a grey area with regards to what Apple will class as an I -app payment and what they don’t, which is primarily why you won’t see it all that often.

This is the tree-hugging model for those wishing to do good. If you are looking to drive revenue but in a ecological and fair way then you can opt for this model to give your wares for free and rely on human nature to reward you accordingly. Assuming you can get past the Apple review process, you may find this works for you but it makes a very big assumption about the generosity of our human nature, and that assumption isn’t always correct.


Simon has worked in the software industry for over 20 years; intent on always producing work of the highest standard and creating software products that genuinely makes things better for people. Simon has previously held positions ranging from Developer, Technical Consultant, Head of Development through to CTO and more recently founder and CEO of several high profile technology companies.

More Posts