How to Monetize an App: Every Model Compared

There are four ways to make money from an app: show ads, sell in-app purchases, charge a subscription, or charge for the download. Most apps that earn real money use two of them together, usually a free app with ads plus an optional purchase that removes the ads or adds something extra.

Which one fits depends on what your users already do in the app. Games with short sessions and a huge audience lean on ads and consumable purchases. Tools that do a job every week lean on subscriptions. A paid download works in a narrow set of cases and is the hardest to grow. The store matters too, because Apple and Google both take a cut of anything sold through their billing systems, and the cut differs by country.

This guide compares the models, explains what the stores charge as of late 2026, runs one example app through three of them and suggests an order for adding them. Money figures from our tables are modelled estimates, and any figure marked as an example rests on the assumptions stated beside it.

The models at a glance

Apple's own business models page groups apps into free, freemium, paid and "paymium" (paid download plus in-app purchases), with ads under free. In practical terms:

Ads

Ads are the default for free apps because they need no persuasion. Every user who opens the app is worth something, even if it is a fraction of a cent. You add an SDK, place a few ad units and get paid per impression, click or completed video.

The size of that fraction depends on where the user lives and which format they see. In our benchmark estimates for AdMob on Android, a rewarded video in a Tier 1 country (US, UK, Canada, Australia) is worth about $12.00 per 1,000 impressions, an interstitial about $8.00 and a banner about $0.90. In Tier 3 markets the same formats fall to roughly $1.40, $0.90 and $0.10. The mobile eCPM benchmarks guide has the full ranges.

Two things decide whether ads work for you.

First, volume. Ads reward apps with many sessions per user per day. A calculator that people open twice a week shows few ads and earns little. A puzzle game played twenty minutes a day shows dozens. The ARPDAU and LTV guide explains the number to track.

Second, tolerance. Rewarded video, where the player chooses to watch in exchange for a bonus, annoys people least. Forced interstitials in the wrong place cost you reviews and retention. The rewarded vs interstitial comparison covers where each fits.

Apple has one rule worth knowing before you plan around ads. Its App Review Guidelines list building apps mainly to display ads, and artificially inflating impressions, as unacceptable business models (section 3.2.2). The app has to do something useful.

For a first network, AdMob is the usual pick: one SDK, banner, interstitial, rewarded and native formats, and mediation built in for when you want other networks to compete. The mediation guide and the best ad networks for apps comparison cover the next step. If children use your app, read ads in kids apps before anything else, because the rules change what you may show.

In-app purchases

An in-app purchase (IAP) is anything bought inside the app. Apple splits these into consumables (coins, gems, lives), non-consumables (a one-time feature such as a filter pack or "remove ads"), auto-renewing subscriptions and non-renewing subscriptions. Google Play's billing system supports two product types: one-time products and subscriptions.

The pattern in free-to-play games is familiar. A small share of users pay, often repeatedly, and they pay far more than an ad would ever earn from them. That is why the in-app purchases vs ads guide treats the two as partners. Ads earn from the many who will never pay, and purchases earn from the few who will.

IAP is better per paying user and much worse per install. It also needs a reason: something scarce, faster or nicer that the free version lacks. If you cannot say what a user gets for $2.99, the price is not the problem.

One store rule matters early. Both stores require their own billing system for digital goods sold inside the app. Google's payments policy lists virtual currency, extra lives, ad-free versions and cloud software as examples, and exempts physical goods and services such as groceries or rides. Apple says the same about features and content (section 3.1.1). Building your own card form for a digital feature is a fast route to a rejection.

Subscriptions

A subscription turns a one-off sale into a recurring one. A user paying $4.99 a month is worth $59.88 a year, which a single purchase rarely matches.

They suit apps where value keeps arriving: new workouts, new lessons, cloud storage, data that stays current, a service that costs you money to run. They suit apps badly when the product is finished the day you ship it. Apple requires auto-renewing subscriptions to provide ongoing value and to last at least seven days (guideline 3.1.2), and people cancel when they stop seeing it.

Details that affect revenue:

• Free trials. Apple does not count free-trial days toward the one-year mark that lowers its commission (more below). Google verifies a payment method before a trial starts and charges the full price when it ends.
• Failed renewals. Google Play gives you a grace period, then an account hold, during which your app should stop granting access. Shorter periods may recover fewer lapsed subscribers. Google's subscription documentation explains both.
• Offers. Apple supports introductory offers, promotional offers, win-back offers and offer codes, described on its subscriptions page. Google calls the equivalent setup base plans and offers.

Decide early which system is the source of truth for "is this user subscribed". Changing it later is painful.

Paid downloads

Charging upfront is simple. No billing logic, no ads SDK, no consent message. A user pays once and has everything.

The trouble is conversion. A paid listing asks someone to spend money before they have used the product, and in most categories a free alternative is one search away. In our view, paid-upfront suits a small group: professional tools with a clear buyer, impulse-priced utilities, and niches where free options are weak. It also gives you no way to earn more from the people who love the app, which is why many paid apps later add a subscription or go freemium.

The store's cut applies to the initial sale, and in the regions where Google's new billing fee applies, it covers the first purchase of a paid app too.

What the stores take

Fees change, and 2026 has been a busy year for them. Treat the numbers below as correct on the day we checked, and confirm on each store's page before you set prices.

Apple. The standard commission is 30%. The App Store Small Business Program cuts it to 15% for developers who earned up to $1 million in proceeds the previous calendar year, and new developers qualify. You have to enrol; it is not automatic. For subscriptions, Apple's page says you keep 70% in the first year and 85% after one year of paid service, or 85% from the start in the Small Business Program. Membership of the Apple Developer Program costs $99 a year.

Google. Play registration is a one-time $25 fee. The service fee changed in 2026. On 30 June 2026 a new structure began in the United States, United Kingdom and European Economic Area. According to the Android Developers Blog, the service fee starts at 10% on your first $1 million of annual earnings and applies at 10% to auto-renewing subscriptions, with a separate 5% billing fee if you use Google Play Billing. Google's service fees page says Australia and Japan followed on 30 September 2026, and gives a separate rate table above the $1 million line that depends on whether a user's install is new or existing. Other countries stay on the older scheme (15% on the first $1 million, 30% above, 15% for subscriptions) until Google rolls the new fees out further.

An example. A user pays $9.99 for a subscription. At Apple's Small Business rate you keep 85%, about $8.49 before taxes. On Google Play in the US, 10% plus the 5% billing fee is 15% in total, so about $8.49 again. A developer above Apple's threshold, in the first subscription year, keeps 70%, about $6.99.

Both stores have rules about pointing users to payment methods outside the app. They differ by country and keep changing, so read the current text before designing a web checkout. At the time of writing, Apple's guideline 3.1.1(a) lets apps on the US storefront link to other purchase methods without an entitlement, while other storefronts need one.

This is general information about how fees work, not tax or legal advice. Ask an accountant how store payouts are taxed where you live.

Matching a model to your app

A rough sorting, based on how people use the app:

Casual and hypercasual games. Ads first, led by rewarded video. Add a "remove ads" purchase and a starter pack. Subscriptions rarely fit unless you run a battle pass or season structure.

Mid-core and strategy games. Purchases do most of the work, because players invest time and money. Ads still cover the many non-payers. Our tables apply a 1.35x category multiplier to ad eCPM for this group against 0.8x for hypercasual, so ads pay better here too.

Utilities. Ads fund the free tier, and a subscription or one-off pro purchase covers heavy features such as batch work or cloud sync. Utilities carry a 0.9x multiplier in our tables, so ad income per user is modest.

Education. Subscriptions or course purchases fit best. Ad income is low (0.85x in our tables) and the audience is often young, which brings restrictions.

Finance. The highest ad multiplier we use, 1.6x, because advertisers in the category bid high. A fee-based product usually earns more, and both stores have special policy rules for lending and trading apps.

Apps selling physical goods or services. Ads may be secondary or absent. Neither store requires its billing system for physical goods, so your normal payment processor stays.

One app, three models

This is an example, not a forecast. Suppose a casual game has 10,000 daily active users (DAU) and about 30,000 monthly active users. Assume AdMob on Android, every user in a Tier 1 country, and the benchmark eCPMs above.

Ads. Each daily user sees 1 rewarded video, 2 interstitials and 5 banner impressions. Per user per day:

• Rewarded: 1 x $12.00 / 1,000 = $0.0120
• Interstitial: 2 x $8.00 / 1,000 = $0.0160
• Banner: 5 x $0.90 / 1,000 = $0.0045

That is an ARPDAU of $0.0325. Across 10,000 users it is $325 a day, or about $9,750 over 30 days. Put the same audience in Tier 3 countries and ARPDAU falls to about $0.0037, which is roughly $1,110 for the month. The AdMob revenue calculator lets you change these inputs, and our AdMob estimates for casual games show a ready-made version.

In-app purchases. Assume 2% of the 30,000 monthly users buy something, averaging $6 a month each. That is 600 payers and $3,600 gross, about $3,060 after a 15% store cut.

Subscription. Assume 1.5% of monthly users subscribe at $4.99 a month. That is 450 subscribers and $2,245.50 gross, about $1,909 after a 15% cut.

Look at what drives each line. The ads figure is large because every user sits in a Tier 1 country, and it shrinks to about a ninth when they do not. The other two depend on the payer rate, which you cannot know until you ship. Halve it and the income halves. Real apps rarely look like one line alone: ads cover the base and purchases add a tail.

For a sense of scale, see how many users you need for $1,000 a month and how much apps make from ads.

Combining models without annoying users

Hybrid is the normal end state. A few combinations that work:

• Ads plus "remove ads". The simplest hybrid. Users who dislike the ads pay once. Keep rewarded video available to them if it feeds your economy, since they opted in to it.
• Rewarded ads as a taste of premium. Let free users watch an ad to try a paid feature once. Some convert.
• Subscription with a free, ad-supported tier. Common in media and utility apps. The free tier has to be good enough to keep people around long enough to convert.
• Consumables plus rewarded video. The ad gives a small amount of the currency players otherwise buy. Set the exchange rate so the paid pack still looks like a bargain.

Mind consent and tracking. In many regions you need a consent message before personalised ads, and on iOS you need App Tracking Transparency for tracking. Both affect ad revenue and are covered in consent messages setup and ATT and iOS ad earnings.

A sensible order

1. Launch with the model that matches your category. If unsure, use rewarded ads and one "remove ads" purchase.
2. Track the basics: sessions per user, ad impressions per user, payer conversion, retention at day 1, 7 and 30.
3. Once you have a few thousand daily users, add mediation so more than one network competes for your inventory.
4. Add a subscription only when you have something that justifies recurring payment.
5. Change one thing at a time, and leave each test running for at least a full week.

Common questions

Can I use ads and in-app purchases together?

Yes, and most free-to-play apps do. Keep the paid path free of ads (a "remove ads" purchase is the standard form) and make sure rewarded ads do not cannibalise items you also want people to buy.

How many users do I need before ads are worth it?

There is no minimum to start, but earnings only matter at volume. Using our tables, 1,000 daily users each seeing eight ads in Tier 1 countries would earn roughly $32 a day. In Tier 3 countries that drops to about $4. Try your own region mix in the calculator.

Does Apple or Google take a cut of ad revenue?

No. The store fee applies to purchases and subscriptions made through its billing system, not to money an ad network pays you. Ad networks take their own share before paying you, and the earnings in your reports are what you receive.

Should I make the app paid and also show ads?

Rarely. People who have paid usually expect no ads, and Apple's guidelines treat apps that exist mainly to show ads with suspicion. Free with ads and a paid upgrade is the more common route.

What to do first

Pick the model that matches your category in the sorting above and write down the monthly income that would make it worthwhile. Then open the AdMob revenue calculator and enter your expected daily users and country mix. If ads alone get you there, build around them. If they fall well short, work out the payer rate a purchase or subscription would need.

When you are ready to build the ad side, the walkthroughs for AdMob on Android and AdMob on iOS cover SDK setup and test ads, and the AdMob payment guide explains thresholds and payout timing. Enrol in Apple's Small Business Program before your first sale, and read Google's fee page for the countries where your users live.