In this guide
- What are the main ways an app can make money?
- When do you have to use Apple's and Google's in-app purchase?
- How do subscriptions work well in an app?
- Can ads pay for an app?
- Is your app meant to make money directly at all?
- How do you check if your monetisation model can pay back the build?
- Frequently asked questions
- Choosing your model
An app makes money in five main ways: subscriptions, one-off in-app purchases, a paid download, advertising, or fees on real-world goods and services. Subscriptions suit apps used regularly; in-app purchases suit games and content unlocks; ads only pay at very large scale; booking, delivery and shopping apps earn through the transaction itself.
The right model follows from what your users value and how often they come back, not from what other apps do. It also determines which payment system you're allowed to use, how much the app stores take, and how your app should be designed. That's why monetisation belongs in your plan before development starts, alongside the budget and platform decisions in our guide to developing a mobile app for your business.
What are the main ways an app can make money?
Each model trades off predictability, user experience and how much of each sale you keep. This table compares them side by side.
| Model | How it works | Best for | Revenue predictability | App store commission applies? |
|---|---|---|---|---|
| Subscription | Recurring weekly, monthly or annual fee for access | Fitness, learning, productivity, media, B2B tools | High once retention is stable | Yes, for digital access sold in-app |
| In-app purchase (one-off) | Pay once to unlock features or content | Games, premium features, content packs | Low to medium | Yes |
| Consumables | Buy credits, coins or boosts that get used up | Games, dating, AI tools with usage limits | Medium, driven by heavy users | Yes |
| Paid download | Pay before installing | Niche professional tools | Low; hard to grow | Yes |
| Advertising | Show banner, full-screen or rewarded video ads | High-volume free apps with long sessions | Medium, depends on traffic | No, but the ad network takes a share |
| Transaction fees | Customer pays for a real-world product or service | Booking, delivery, e-commerce, marketplaces | Tied to order volume | No; use your own payment provider |
| Indirect | App is free; it supports an existing business | Loyalty apps, client portals, staff tools | Measured in retention and savings | No |
The most important line in that table is the last column. Whether Apple's and Google's in-app purchase rules apply to you changes your margins and your checkout design.
When do you have to use Apple's and Google's in-app purchase?
You generally have to use the stores' in-app purchase systems when you sell digital goods or services consumed inside the app, such as premium features, subscriptions to content, or virtual currency. Physical goods and real-world services, like a haircut, a food order or a parcel delivery, can use your own payment provider.
In practice:
- A meditation app selling a monthly subscription: in-app purchase.
- A salon booking app taking a deposit for an appointment: your own provider, such as Stripe or Razorpay.
- An online clothing store app: your own provider.
- A course app selling video lessons: in-app purchase if sold inside the app.
The stores' standard commission on digital sales has long been 30%, with a reduced 15% rate under programmes for smaller developers and, in many cases, for subscriptions after the first year or from the start depending on the store. Rules on linking to outside payment options have been changing in some regions, including the EU and the US, following regulation and court rulings. Check the current App Store and Google Play payment terms for your markets before setting prices, because the details shift.
Some B2B and "reader" apps, where customers subscribe on your website and simply log in on mobile, can avoid in-app purchase entirely. Whether that's allowed depends on the app's category and current store rules, so plan it with your developer early.
How do subscriptions work well in an app?
Subscriptions work when the app delivers fresh value every week, and fail when users feel they're paying to rent something static. Retention, not sign-ups, decides whether a subscription app survives.
Decisions to make before you build the paywall:
- Hard or soft paywall. A hard paywall blocks use until payment; a soft one gives a useful free tier and charges for more. Soft paywalls attract more users; hard paywalls can convert better if the value is obvious from the store listing.
- Free trial length. Long enough for a user to reach the core benefit at least once or twice. Remind users before the trial converts; surprise charges create refunds and bad reviews.
- Monthly vs annual. Offer both. Annual plans improve cash flow and reduce cancellations; monthly plans lower the barrier.
- Regional pricing. Both stores support different price points per country. A price that works in the US may block growth in India or Southeast Asia.
- Cancellation clarity. Subscriptions are managed through the user's store account. Explain clearly how to cancel; it reduces complaints.
If you're building a B2B app, the logic is closer to SaaS pricing (per seat, per usage or tiered), which we explain in SaaS pricing models explained. And if billing happens on the web, our comparison of subscription billing with Stripe, Razorpay and Paddle covers the payment side.
Can ads pay for an app?
Ads can pay for an app only when it has a large audience that spends a lot of time in it. Each ad impression earns very little, so a business app with a few thousand users will rarely cover its maintenance from advertising.
Ad formats compared:
- Banner ads: least intrusive, lowest earnings.
- Interstitials (full-screen): earn more but interrupt users; place them only at natural breaks.
- Rewarded video: the user chooses to watch in exchange for something, such as extra lives or a free credit. Generally the best-tolerated format.
Ads also bring privacy obligations. Ad SDKs (the code libraries that serve ads) collect data that you must disclose in Apple's App Privacy details and Google's Data safety form, and on iPhone, tracking across other companies' apps requires the user's permission. Many apps combine ads with a paid "remove ads" option, which turns the most engaged users into paying ones.
Is your app meant to make money directly at all?
Often it isn't, and that's fine. Many business apps earn their keep by making existing customers buy more often or by saving staff time.
A loyalty app that brings a café's regulars back one extra time a month, a client portal that cuts support calls, or a driver app that speeds up deliveries all pay for themselves without a price tag. For these, measure success in repeat purchases, average order value, retention or hours saved. GRWW's own Ops Console, for example, is internal software built to run our CRM, leads, invoices and client portal; its value is operational, not a revenue line.
How do you check if your monetisation model can pay back the build?
Do the break-even sum before you build. Here's an illustrative example using typical cost ranges; the numbers are hypothetical, not a forecast.
| Item | Illustrative figure (USD) |
|---|---|
| Build cost for a mid-size subscription app | $60,000 |
| Annual maintenance (15–25% of build) | $9,000–15,000 |
| Subscription price | $6 per month |
| Store commission at a 15% rate | about $0.90 per subscriber per month |
| Net revenue per subscriber | about $5.10 per month, or about $61 a year |
| Subscribers needed just to cover maintenance | roughly 150–250 paying users, all year round |
| Subscribers needed to recover the build in two years | roughly 500 more, on top of that |
This ignores marketing costs, refunds, taxes and churn, all of which raise the numbers. If the paying-user count you need looks unrealistic for your market, change the model, the price or the scope before writing code. Trimming version one, as described in our guide to planning features for your first app version, is often the simplest lever.
Frequently asked questions
Which app monetisation model makes the most money?
There's no single winner. Subscriptions tend to produce the most predictable revenue for apps used regularly, while games often rely on in-app purchases from a small share of heavy users. The best model is the one that matches how often and why people use your app.
Can I take payments through Stripe or Razorpay inside my app?
Yes, for physical goods and real-world services such as bookings, deliveries and retail orders. For digital goods and subscriptions used inside the app, the stores generally require their own in-app purchase systems. Rules vary by region and change over time, so confirm before you build.
Should a new app be free or paid?
Most new apps launch free with a paid tier, because a price before download sharply limits who tries it. A free tier lets users experience value first. Paid downloads only tend to work for niche tools with a clear, known audience.
How much do Apple and Google take from app sales?
The standard commission on digital sales has been 30%, with a 15% rate available in many cases for smaller developers and for subscriptions. Physical goods and real-world services sold through your own payment provider don't pay this commission. Check current terms, since regional rules have been changing.
When should I add monetisation to my app?
Plan it before development, even if you switch it on later. The model affects your payment setup, screens, analytics and store review. Adding a paywall to an app designed without one usually means reworking parts of it.
Choosing your model
The right monetisation model makes the app's design, payments and budget fall into place; the wrong one makes every feature a compromise. If you want a second opinion on the numbers before you build, look at what we offer and talk to us about a fixed-price build.