Short answer: match the model to how the app delivers value. Ongoing value, such as content, sync or server-side features, suits a subscription. A finished tool suits a one-time purchase. Games and high-volume casual apps suit ads combined with in-app purchases. Apps that arrange physical goods or real-world services take a commission or fee through an ordinary payment provider. Business software is often best sold outside the stores entirely, with the app as a free companion. Most successful apps combine two of these.
The models
Paid download
The user pays once in the store before installing. It is the simplest model to build, since the store handles everything, and the hardest to sell, because people pay before they have seen the product. It survives mainly in professional tools, niche utilities and premium games with an existing reputation.
Subscription
Recurring payment for continued access, usually monthly or yearly, often with a free trial. Revenue is predictable and scales with retention, which also means the product has to keep earning its fee. Subscriptions carry the most engineering work: plans, trials, renewals, grace periods, cancellations, upgrades and restoring access on a new phone.
In-app purchases: non-consumable
A one-time purchase inside a free app that stays with the account permanently: removing ads, a pro feature set, a level pack, a cosmetic skin. Users understand it and it is comparatively simple to build. Revenue per user is capped at the price of what you offer.
In-app purchases: consumable
Items that are bought, used up and bought again: game currency, credits, boosts, extra AI generations. There is no ceiling per user, which is why games rely on them. They need a server-side balance if purchases must survive reinstallation or work across devices, and careful design so the app remains fair to people who do not pay.
Advertising
The app is free and an ad network pays you for impressions and clicks. Nothing is asked of the user, so it works where willingness to pay is low. It requires volume, affects the experience, and brings consent and privacy obligations.
Freemium
Less a separate model than a structure: a free tier that is useful in its own right, and a paid tier delivered by subscription or one-time purchase. The design question is where to draw the line. Too generous and nobody upgrades; too stingy and nobody stays long enough to consider it.
B2B licence sold outside the stores
The customer is a company. It signs a contract or subscribes on your website, pays by invoice or card, and its staff download a free app and log in. Apps for field teams, clinics, logistics or any tool where the employer pays fit this model. No store commission applies, because nothing is sold in the app. The stores permit this pattern for business and enterprise services, with conditions about what the app may say about purchasing; check the wording of the current guidelines for your case.
Comparison
| Model | Best for | Revenue pattern | Store commission | Main risk |
|---|---|---|---|---|
| Paid download | Specialist tools, premium games with a following | One payment per user | Yes | Few people pay before trying |
| Subscription | Content, fitness, education, productivity, anything with server costs | Recurring; depends on retention | Yes, when sold in the app | Churn; subscription fatigue |
| Non-consumable purchase | Utilities, remove-ads, feature packs, cosmetic items | One or a few payments per user | Yes | Low ceiling per user |
| Consumable purchase | Games, credit-based services | Repeat purchases, concentrated in a minority of users | Yes | Balance and fairness; refund abuse |
| Advertising | Games, utilities and content apps with large free audiences | Small amount per user per day | No | Needs scale; harms experience if overdone |
| Commission on physical goods or services | Marketplaces, booking, delivery, e-commerce | Percentage of each transaction | No; paid through an external processor | Payment processing costs; users settling outside the platform |
| B2B licence outside the stores | Workforce, operations and professional tools | Contracts or seats, invoiced | No | Longer sales cycles |
Store billing rules, explained carefully
Both Apple and Google divide what you sell into two groups, and the group decides how you are allowed to charge.
| What is sold | Examples | How you must charge |
|---|---|---|
| Digital goods and services used in the app | Premium features, subscriptions to content, game currency, removing ads, extra storage | Generally the store's own billing system, with its commission |
| Physical goods and services delivered outside the app | Products shipped to a home, taxi rides, food delivery, cleaning, hotel rooms, tickets to physical events | An external payment provider such as a card processor. Store billing is not used |
The commission on the first group is 15–30% depending on which programme you qualify for. Both stores offer a reduced rate to smaller developers, subject to a revenue ceiling and, on Apple's side, enrolment, and both treat subscriptions more favourably than one-off purchases in some circumstances. The programmes differ in detail and have been revised several times, so read the current terms instead of trusting a figure quoted in an article, including this one.
Several grey areas deserve attention before you design the payment flow:
- One-to-one services delivered online, such as live tutoring or consultations between two people, have been treated differently from one-to-many digital content. The definitions are narrow.
- Apps that only let people use what they bought elsewhere, such as reading, music and video services and many business tools, may be permitted to operate without in-app purchase, under conditions about what the app may link to or say.
- Telling users about cheaper prices on your website was long prohibited and is now allowed in some countries following court rulings and regulation, sometimes with a reduced commission still payable. The position differs between the United States, the European Union, South Korea and elsewhere, and between Apple and Google.
- Alternative billing programmes exist on Google Play in some markets, where your own billing can be offered beside Google's at a slightly reduced service fee.
The honest summary is that the default rule is stable and the exceptions are not. If your margins depend on an exception, confirm it against the current developer policy for each store and country at the time you build, and design the app so the payment method can be changed without rewriting the product. If avoiding store billing matters more to you than store presence, a web app or PWA with web checkout is the clean alternative.
Not legal advice. Store terms are contracts and regional rules are law. For a business whose economics hinge on them, have the final flow checked against the live policy text.
How ad revenue works
Ad networks pay mostly per thousand impressions, a rate known as eCPM. Your income is simple arithmetic:
Daily ad revenue = daily active users × ad impressions per user × eCPM ÷ 1,000
We are not going to quote eCPM figures. They vary several-fold by country, format, season and category, and any single number would be wrong for you. What can be said reliably:
- Format matters. Banners pay least per impression. Full-screen interstitials pay more. Rewarded video, which the user chooses to watch in exchange for something in the app, usually pays most and is resented least, because it is voluntary.
- Geography matters. Advertisers pay more to reach users in high-income countries. An audience concentrated elsewhere earns less per impression.
- Session design matters. Games have natural breaks between rounds where an ad is tolerable. A utility opened for ten seconds has almost no ad inventory.
- Volume is the requirement. Work the formula backwards: decide what monthly income would justify the app, and see how many daily users that implies at a range of plausible rates. For many niche apps the answer rules ads out as the primary model.
- Ads cost retention. Every interstitial loses a few users. The usual remedy is a hybrid: ads for free users and a purchase that removes them.
BBR's own game, Grow.io, combines AdMob ads with in-app purchases through Google Play Billing, which is the standard arrangement for a free arcade game. We do not publish its revenue, so treat it as an example of the implementation, not of results.
Ads also bring obligations: a consent flow for users in the EEA and UK, the tracking permission prompt on iOS, an accurate data safety declaration, stricter rules if children are in the audience, and placement policies that prohibit ads appearing unexpectedly. The Android side of those is in our step-by-step Google Play publishing guide.
Choosing a model by app type
| App type | Usual primary model | Common addition |
|---|---|---|
| Casual or arcade game | Ads, with rewarded video | Remove-ads purchase, cosmetic items, currency packs |
| Content, learning, fitness, meditation | Freemium subscription with a trial | Yearly plan at a discount |
| Productivity tool with sync or AI features | Subscription, since you carry running costs | Credit packs for heavy usage |
| Offline utility with no server | One-time pro purchase, or paid download | Light ads in the free version |
| Data or information app with a broad free audience | Ads | Subscription or purchase that removes ads and adds advanced features |
| Marketplace, booking, delivery | Commission or service fee through a payment provider | Provider subscriptions, paid placement |
| E-commerce | Product margin; the app is a sales channel | Loyalty membership |
| Workforce, operations, professional B2B tools | Licence or seats sold outside the stores | Setup and integration fees |
| Companion app for hardware or an existing service | None directly; it supports the main product | Premium digital features via subscription |
Three decision rules help when the table does not settle it:
- If serving each user costs you money every month, charge every month. AI features, storage and live data all fall here. One-time pricing with recurring costs is a slow leak.
- If the buyer is not the user, sell outside the app. Employers, schools and clinics buy through contracts, not app stores.
- If you cannot describe what the paid tier adds in one sentence, it is not ready to be sold. Launch free, watch what people use most, and charge for more of that.
For marketplaces specifically, the payment mechanics are a project of their own, covered in what a two-sided marketplace costs to build.
What each model adds to the build
Planning estimates for a cross-platform app covering iOS and Android, in person-weeks, where one person-week is about 40 hours. Multiply by your team's rate as shown in our app cost breakdown: $2,000 per person-week at $50 an hour, $6,000 at $150 an hour.
| Model | Added effort | Where the work goes |
|---|---|---|
| Paid download | Close to zero | Store pricing setup. No trial is possible, so the listing has to do the selling |
| Ads | 1–2 person-weeks | SDK integration, consent flow, placements, frequency rules, test devices, store declarations. Mediation across several networks adds more |
| Non-consumable purchase | 1–2 person-weeks | Store products on both platforms, purchase and restore flows, error and pending states, paywall screen |
| Consumable purchases | 1.5–3 person-weeks | The above plus server-side receipt validation and a balance ledger that cannot be double-credited |
| Subscriptions through the stores | 1.5–3 person-weeks | Plans, trials, entitlement checks, server notifications for renewals and cancellations, grace periods, restore, paywall design. A subscription management service can cut this in exchange for a fee |
| Subscriptions sold both in the app and on the web | 3–5 person-weeks | Two billing systems feeding one entitlement record, plus account screens that explain where to manage each |
| B2B licence outside the stores | 2–5 person-weeks | Web billing or invoicing, organisation accounts, seat management, an admin view for the customer |
| Marketplace commission with split payouts | 3–5 person-weeks | Seller onboarding, payment splitting, refunds and payout failures |
So a free game with ads and a handful of purchases adds roughly 2–4 person-weeks over the game itself, or about $4,000–$8,000 at $50 an hour. A content app sold by subscription in both stores and on the web adds 3–5 person-weeks, about $6,000–$10,000 at the same rate.
Two costs are routinely missed. The first is testing: purchases have to be tested from store-installed builds with test accounts on both platforms, through cancellation, refund, renewal and reinstall, and it is slow. The second is upkeep. Billing libraries, ad SDKs and consent requirements are updated on the stores' schedules, not yours, and that belongs in the yearly maintenance budget.
A sequence that works for most first releases
- Decide the long-term model before design starts, so the screens, the data model and the account system allow for it.
- Classify what you sell as digital or physical under the store rules, per country, and confirm the billing method that follows.
- Launch with the simplest version of the model. One plan, one price, one paywall. Or launch free with analytics if you are still learning what people value.
- Instrument it. You need to see how many users reach the paywall, how many start a trial or purchase, and how many are still paying in month three.
- Change one thing at a time: price, trial length, paywall position, ad frequency. Each change needs enough users to show a difference, which is another reason volume comes first.
If you would like a second opinion on which model fits your product and what it does to the estimate, BBR's mobile app development page explains how we scope billing and ads work alongside the rest of the app.