App monetisation models: how apps make money

The short answer

Apps make money in a few ways: users pay directly through paid downloads, in-app purchases or subscriptions, advertisers pay for attention, the app sells something outside it such as goods or bookings, or businesses pay for access. Choose by asking who gets value, how often, and if you already sell something the app can support.

App monetisation: who pays, and for what

App monetisation (spelt monetization in the USA) is the way an app produces income. The first question is not which tool to install but who is paying. There are four possible payers.

• The user pays the store directly, through a paid download, a one-off purchase inside the app, or a subscription.
• An advertiser pays to be shown to the user.
• A customer pays your business for something that is delivered outside the app, such as goods, a booking, a service or a delivery. The app is the sales channel.
• A company pays for access, per user or per site, because the app is a work tool.

Guides tend to dwell on the first two. The last two matter just as much. If you already run a business and the app serves it, you may not need a separate revenue model at all. The app earns by bringing in orders, saving staff time or keeping customers.

The main models side by side

Many apps combine two. A game may offer in-app purchases and rewarded ads. A news app may have a free tier with ads and a paid tier without them. Start with one model, make it work, and add a second only when the first is stable. The store listing carries part of the sales message, including how purchases are described, and app store optimisation basics covers what to put there.

Ads, purchases and subscriptions compared

Advertising

Advertising earns small amounts per view or tap, so it matters only when many people use the app often. It also changes the experience. Banners take up room, full-screen ads interrupt tasks, and ad code can slow screens. Ad networks collect data about users, which creates duties in your privacy policy and, in some countries, a duty to ask for consent. Apple and Google both publish rules on this that change, so check the current documentation and ask a lawyer about consent in the countries where your users live.

In-app purchases

An in-app purchase is a payment made inside the app for something the app provides. It suits apps where people buy at the moment of need: extra credits, a premium feature, a content pack. You are paid for each item and do not rely on people coming back every month. The weakness is that most users of a free app never buy anything, so you need enough users and a reason to buy that is clear within a few minutes of use.

Subscriptions

A subscription charges on a repeating schedule for continuing access. It suits a service that keeps delivering: new sessions each week, live data, storage, a tool that stays useful. If the app has little new to offer after the first month, subscribers cancel. Many people also feel fatigue about subscriptions, so the app should show what they get before it asks.

Put simply, ads monetise attention. Purchases and subscriptions monetise value: a purchase pays for a moment of need, a subscription for a continuing service.

Store rules shape what you can charge for

Apple and Google both have rules about how digital items sold inside an app must be paid for, and the rules differ by country and change. In general they are tightest for digital goods used inside the app, such as extra levels, premium content or a subscription to the app's own features, and looser for physical goods and services delivered outside it, such as a parcel or a haircut. Treat that as a starting point only. Read the current documentation for each store before you design any payment flow, and ask your developer to point to the rule behind each choice.

A web app sits outside the stores, so different rules may apply to it. Progressive web apps explained for business owners describes what a web app can and cannot do on a phone, which helps if you want to test demand before committing to a store app.

Five questions that choose the model

1. What does the user get, and how often? A one-time result points to a purchase or a paid download. Repeated value points to a subscription.
2. Who is the buyer? Often the user is not the one who pays: a manager buys for staff, a parent buys for a child. That points to a business licence or a family arrangement.
3. Do you already sell something? If the app brings people to goods or services you provide, the model may be no direct app revenue, and the question becomes how to measure the orders it brings.
4. How many users are realistic in the first year? Ads need volume. A subscription can work with a small audience if each user gets a lot of value.
5. What will you have to keep delivering? A subscription is a promise to keep adding value, so check that you have a content plan and a backend to carry it.

Examples by type of app

A booking app for a clinic or a salon usually has no revenue model of its own. The money is the appointment, and the app's job is to fill the diary with fewer calls. A fitness app with fresh sessions every week fits a subscription, perhaps with a free tier to try first. A single-player puzzle game often relies on ads, on purchases such as hints, or on a one-off purchase that removes the ads.

A field-service tool for a company's engineers is licensed to the company, per user. A reference app with a stable library of content might be a paid download, or a subscription that pays for updates. A local retailer's app is a sales channel: revenue is tracked as orders, and the app succeeds if reordering is quick. Each example answers the same question in a different way: where does the value land, and who is willing to pay for it?

Test the model before you build it

A model that looks right on paper can fail with real users, and the cheap tests come before development. Show a mock-up to people in your target group and ask what they would pay for. Run a pilot with a small group, free at first and then paid. Put up a landing page that describes the paid offer and count sign-ups. A clickable prototype is enough for all of these. If you have no audience yet, expect the first version to teach you more than it earns.

Keep the choice reversible where you can. Moving from paid to free, or from a one-time purchase to a subscription, upsets people who paid under the old terms. Decide how you will treat existing users before you change anything.

What the model means for the build

The model changes the technical scope. Subscriptions and purchases need a backend that records who has paid and keeps that in step with the store. Ads need an ad network and consent handling. Business licences need accounts, roles and an admin view. Put the chosen model in the brief, and ask the developer to list the extra work it creates.

Marketing links matter more than people expect. A paid campaign or an email offer should open the exact offer screen in the app, not the home screen. Deep links explained for apps shows how that works. Keep the billing, advertising and store accounts in the business's name, as the website and app handover guide sets out, and settle who maintains billing changes when you compare in-house, agency and freelancer routes. To scope the app itself with a team, see the mobile app development service page.

Related guides

• Mobile app development
• App store optimisation basics
• How to prepare your business for a website or app handover
• In house vs agency vs freelancer for app development
• App store screenshots and previews how to make them
• What to build in the first version of your app

Questions and answers

How do apps make money?

Apps earn through paid downloads, in-app purchases, subscriptions, advertising, sponsorship, business licences, or by acting as a sales channel for goods and services the business delivers elsewhere. Many combine two. The right one depends on who gets the value, how often, and who is willing to pay.

What is the difference between ads, purchases and subscriptions?

Ads are paid for by advertisers and depend on a large, returning audience. An in-app purchase is a payment by the user for a specific item or feature. A subscription is a repeating payment for continuing access, and it only lasts if the app keeps adding value.

How do I choose a monetisation model?

Start with who benefits and how often. A one-off result suggests purchases, repeated value suggests a subscription, a large daily audience suggests ads, and an app that supports an existing business may need no separate model. Test the idea with a prototype or pilot before building it.

Can an app use more than one model?

Yes. Games often mix purchases and ads, and content apps often offer a free tier with ads and a paid tier without. Start with one model and add another once the first is working, so you can see what each one does to the experience.

Can an app earn money without ads or purchases?

Yes. An app can bring in bookings or orders, reduce the cost of serving customers, or be licensed to businesses. In those cases the app does not charge users, and its value is measured in the business results it supports.

Do the app stores take a share of what I earn?

The stores charge fees on payments made through their billing systems, and the terms differ by country and change over time. Check the current documentation for each store, and ask your accountant how store sales are taxed and reported where you trade.