How to Monetize a Mobile App (Indie Dev Guide)

Short answer: To monetize a mobile app as an indie developer, pick one main model that matches how people use your app, then add one or two supporting ones. For apps people rely on every week, that is usually a subscription with an annual plan and a free trial, plus a lifetime unlock. For casual games, it is usually rewarded ads plus a paid "remove ads" option. Add a web checkout for US users and a tip jar if your audience likes you.

That is the menu in one paragraph. The rest of this guide goes through every model Apple and Google allow, what each store and tool takes, which model fits which kind of app, a worked revenue example, the mistakes we see most, and a 30-day plan to switch revenue on.

TL;DR#

• Apple lists four business models: free, freemium, paid and paymium (Apple business models). Subscriptions are sold as one kind of in-app purchase inside those models.
• Four in-app purchase types: consumable, non-consumable, auto-renewable subscription and non-renewing subscription (Apple In-App Purchase).
• Store cut for a small developer: 15% on Apple through the Small Business Program; on Google Play in the US, UK, EEA, Australia and Japan, a 10% service fee on the first $1M plus a 5% billing fee when Google Play Billing takes the payment (Android Developers Blog, Play Console Help).
• Upfront beats freemium at the start, not at the end: RevenueCat says apps that ask for money upfront "convert 5x better than freemium (10.7% vs. 2.1%)", but "after one year, retention for both models is nearly identical" (RevenueCat State of Subscription Apps 2026).
• Ads fit games and high-frequency apps. AdMob pays monthly once your balance passes $100 (AdMob payment thresholds).
• US link-outs are allowed, with an open fee question. Apple's guideline 3.1.1(a) lets US storefront apps link to other purchase methods (App Review Guidelines); the courts have said Apple may charge a reasonable, cost-based commission on those sales (Fenwick).

Disclosure: ZeroRaised publishes this guide and runs a launch site for bootstrapped products. ZeroRaised has no commercial relationship with Apple, Google, RevenueCat, Superwall, Adapty, Qonversion, Stripe or any other company named here, and earns nothing if you use them. Prices, rates and quotes come from the linked pages as checked on 9 Nov 2026. Advice marked "our read" is our own opinion.

What "monetize an app" really means for an indie developer#

App monetization is the set of ways an app turns users into revenue: charging for the app, charging inside it, showing ads, or selling something off the app that the app makes possible. For a funded company, monetization can wait while growth is bought. For a solo developer, the app usually has to pay for itself early, because there is no runway to burn while you figure it out.

That changes the question. You are not asking "what is the most money this app could ever make?" You are asking "what is the simplest model that pays me fairly from the first month, without wrecking the experience that makes people stay?"

Three facts shape every answer:

1. The stores take a cut of digital sales. Anything that unlocks features or content inside the app is a digital sale, and Apple's rule is blunt: "If you want to unlock features or functionality within your app, (by way of example: subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version), you must use in-app purchase" (App Review Guidelines, 3.1.1).
2. Usage pattern decides the model. An app opened ten times a day is a different business from one opened once a month.
3. You can combine models, and most successful indie apps do. One main engine, one or two supporting ones.

If you have not shipped yet, read how to launch a bootstrapped app alongside this guide. Monetization decisions are much easier to get right before launch than to retrofit after.

The full menu: every way a mobile app can make money#

Here is every model worth considering, grouped by where the money comes from. Apple's own vocabulary is a good starting point because it is the one App Review uses.

Apple's four business models#

Apple's business models page describes four:

Apple's "free" model has sub-types, including free with display advertising, free with physical goods and services, and Reader apps. In practice, "free" for an indie developer usually means ads, or an app that supports a business that earns elsewhere (a physical product, a web SaaS, a service).

The four in-app purchase types#

Inside freemium and paymium, you sell through in-app purchases. Apple lists four types (In-App Purchase), and its business models page describes each:

• Consumable: "Consumable in-app purchases are depleted as they're used, and can be purchased again." Think gems, credits, extra lives or AI generations.
• Non-consumable: "Non-consumables are purchased once and do not expire, such as additional filters in a photo app." This is how you sell a "Pro unlock" or a lifetime plan.
• Auto-renewable subscription: "Users are charged on a recurring basis until they decide to cancel."
• Non-renewing subscription: "This type of subscription does not renew automatically, so users need to renew each time." A season pass is the classic example.

Google Play has equivalent product types (one-time products and subscriptions). The names differ; the shape of the decision is the same.

Everything else#

Beyond the store models, there are revenue streams that sit around the app:

• Advertising: banners, interstitials, rewarded video and native ads, usually through Google AdMob or a mediation platform.
• Web checkout (web-to-app): selling a subscription or unlock on your own site with a processor like Stripe, then unlocking it in the app via the user's account.
• Tips: a tip jar inside the app (sold as an in-app purchase) or a link to a creator support page outside it.
• Sponsorships: a single sponsor for a niche app or its newsletter, paid as a flat monthly fee.
• Affiliate revenue: commission on products the app recommends, where it is genuinely useful to the user.
• Physical goods and services: apps that sell real-world things (food, tickets, merchandise, coaching) take payment outside in-app purchase.
• Licensing and B2B: selling a team or school version, or white-labelling the app for a business.

One thing is not on the menu: selling user data. Apple's guideline 5.1.2 requires permission before you use, transmit or share someone's personal data, and says data collected from apps may only be shared with third parties to improve the app or serve advertising (App Review Guidelines, 5.1.2). Our read: even where a law might allow it, it is a bad trade for an indie app, because trust is the asset that makes everything else on this list work.

What the stores take (the 2-minute version)#

We cover commissions in full in our app store fees guide. The short version for a small developer:

• Apple: the Small Business Program "features a reduced commission rate of 15% on paid apps and Apple In-App Purchases" for developers who earned no more than 1 million USD in proceeds. Outside the program, Apple's subscriptions page says you receive 70% of a subscription price in a subscriber's first year and "85% of the subscription price" after one year of paid service. Membership is a "$99 annual membership" (Apple Developer Program).
• Google Play: from 30 June 2026 in the US, EEA and UK, "the service fee starts at 10% on your first $1M (USD) in annual earnings", and "this 10% service fee also applies to all auto-renewing subscriptions". On top, "the billing fee is set at 5%" in those markets when Google Play Billing processes the sale (Android Developers Blog). Google's service fees page gives the rollout dates as "June 30, 2026 for the EEA, UK, and US; September 30, 2026 for Australia and Japan", and other markets still use the older 15% tier for the first $1M. Registration is "a US$25 one-time registration fee" (Play Console Help).

Our read: enrol in Apple's Small Business Program on day one. It is the single biggest margin decision most indie developers will make, and it takes minutes.

Model by model: how each one works and who it suits#

Subscriptions#

How it works: users pay weekly, monthly or yearly until they cancel. You sell it as an auto-renewable subscription, usually behind a paywall with a free trial.

Who it suits: apps that deliver ongoing value: habit trackers, fitness and health, journaling, language learning, photo and video tools with new content, anything with a server cost (sync, AI, cloud storage), and apps you will keep improving for years.

What the data says: RevenueCat's State of Subscription Apps 2026 covers 115,000+ apps and says "Trials of 17+ days convert 70% better than short trials (42.5% vs. 25.5%)" and that "$23 annual RLTV per payer is the global median" (RevenueCat). It also says "AI-powered apps generate 41% more revenue per payer, but they churn 30% faster", which matters if your app is built on a model API with a per-request cost.

Offer tools Apple gives you: introductory offers ("Customers can redeem one introductory offer per subscription group"), free trials, promotional offers for existing or lapsed subscribers, win-back offers and offer codes (Apple subscriptions).

Watch out for: subscription fatigue. A subscription on an app that does one simple thing, once, invites one-star reviews. If you are torn between a subscription and a one-time price, our subscription vs one-time purchase guide works through the revenue maths, so we will not repeat it here.

Paid upfront#

How it works: users pay once to download. No paywall, no ads, no in-app purchases (or very few).

Who it suits: niche professional tools with a clear job, apps for audiences that already trust you (an existing blog, newsletter or community), and pro-grade utilities where the buyer knows exactly what they want.

Watch out for: the price is a wall in front of the App Store page. People cannot try before they buy, so screenshots, reviews and your own audience do all the selling. Paid apps also give you no recurring revenue to fund updates, which is why many developers move to paymium or a subscription later.

Freemium#

How it works: the app is free to download and use, with a premium tier or extra content sold inside. The free version must be good enough to keep people around, and the paid version must be clearly better.

Who it suits: apps with a natural free/paid line (number of items, export quality, sync across devices, advanced features), apps that grow by word of mouth, and apps where the core value takes a few days to feel.

What the data says: RevenueCat reports freemium's download-to-paid median at 2.1%, against 10.7% for apps that ask for money upfront, while noting that one-year retention is "nearly identical" for both (RevenueCat). Our read: freemium is a growth choice more than a revenue choice. It trades early conversion for reach. That trade only works if the free tier actually spreads.

Hard paywall (with a trial)#

A hard paywall means the app asks for payment, usually via a free trial, before the user gets the core value. In RevenueCat's terms, these are the apps that "ask for money upfront". It is the model behind the 10.7% figure above.

Who it suits: apps where the first session can show the value (a strong onboarding, a demo result, a personalised plan), and categories where users expect to pay, such as fitness programmes or language courses.

Watch out for: a hard paywall with a weak onboarding just converts fewer people faster. Your first screen has to earn the right to ask.

Paymium#

How it works: a paid download with optional in-app purchases on top, for example a paid camera app that sells extra film packs.

Who it suits: apps with a loyal audience and a clear core, where extras are genuinely extra. Our read: it is the rarest model for new indie apps, because it combines the friction of a paid download with the complexity of in-app purchases.

Consumables and credits#

How it works: users buy packs of something that runs out: coins, hints, AI credits, exports.

Who it suits: games, and apps with real per-use costs (AI image generation, transcription minutes). Credits let heavy users pay more and light users pay less.

Watch out for: Apple requires apps offering "loot boxes" or other randomised paid items to disclose the odds of each item before purchase (App Review Guidelines, 3.1.1). Keep consumables honest: users should always know what they are buying.

Lifetime purchase#

How it works: a one-time, non-consumable "unlock everything forever" option, usually shown next to monthly and annual subscription plans.

Who it suits: almost any subscription app with a vocal anti-subscription audience. It captures buyers who would otherwise leave a one-star review about the subscription.

Our read on pricing: price lifetime high enough that it does not cannibalise the annual plan. Many developers anchor it at a multiple of the annual price; pick a multiple you would be happy with if a large share of buyers chose it, because some will. Also remember that a lifetime buyer still costs you server time and support for as long as the app runs. If your app has meaningful per-user costs (AI calls, storage), think twice before offering lifetime at all.

Advertising#

How it works: you show ads from a network (most indie developers start with Google AdMob) and earn per impression or per click. A mediation layer such as AdMob mediation lets several networks compete for each slot.

Formats:

• Rewarded ads: AdMob says "Rewarded ads are served after a user explicitly chooses to view a rewarded ad" and are "shown to users in exchange for a reward, such as an extra life or in-app currency" (AdMob Help).
• Interstitials: "Full-page ads appear at natural breaks and transitions, such as level completion" (AdMob Help).
• Banners and native ads: smaller, always-on placements inside the interface.

Placement rules: AdMob's policy says "Do not place interstitial ads on app load and when exiting apps as interstitials should only be placed in between pages of app content", and "You should place no more than one interstitial ad after every two user actions within your app" (AdMob disallowed interstitial implementations).

How you get paid: "The AdMob payment cycle is monthly." If your balance exceeds the payment threshold and there are no holds, payment is issued "on or around the 21st of the month" (AdMob payments). The USD payment threshold is $100 (AdMob thresholds). For a tiny app, that means your first payout may take a few months.

Rewarded vs interstitial, our read: rewarded ads are the indie-friendly format because the user chooses them and gets something they want. Interstitials earn on every natural break but cost you goodwill. For a casual game, start with rewarded ads tied to a meaningful reward, add a "remove ads" non-consumable, and only add interstitials if your retention holds up when you test them. For a productivity app, we would not use interstitials at all.

What we deliberately do not quote: typical eCPMs. They vary by country, format, category and season, and we have not found a current named benchmark we could verify today. Use the numbers in your own AdMob dashboard after two weeks of live traffic.

Web checkout and external purchase links#

How it works: the user pays on your website through a processor like Stripe, then signs in to the app and the purchase unlocks. On Android and on iOS in the US, you can now point users from the app to that checkout.

The Apple rules, carefully: Apple's guideline 3.1.1(a) covers links to other purchase methods. It says entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps", and that the ban on such links in other storefronts does not apply in the United States storefront (App Review Guidelines). Outside the US, link-outs depend on regional entitlements and terms.

The fee question is still open. This change followed the Epic v. Apple case. As summarised by law firm Fenwick, the district court had "enjoined Apple from imposing any commission or fee on linked-out purchases". In December 2025 the Ninth Circuit called that total ban overbroad, said "Apple should be permitted to charge a commission based on costs that are genuinely and reasonably necessary" for coordinating external links and linked-out purchases, and remanded the issue. Our read: treat today's US link-out as a cheaper channel, not a guaranteed free one, and check our app store fees guide and Apple's guideline before you build pricing that depends on it.

Google Play: in the US, UK and EEA (and, per our app store fees guide, Australia and Japan since 30 September 2026), developers "can offer an alternative billing system or link users to their own website for purchases, alongside Google Play's billing", and "for transactions processed via alternative billing or external web links, the billing fee does not apply" (Android Developers Blog). Google's service fee table still applies, so check the service fees page for your case.

What the processor takes: Stripe's US standard rate is "2.9% + 30¢" per successful transaction for domestic cards, with "+ 1.5%" for international cards and "+ 1%" if currency conversion is required (Stripe US pricing). You also handle sales tax and VAT yourself unless you use a merchant of record.

Who it suits: apps with a web presence or an audience outside the store (a newsletter, a YouTube channel, a web version), and apps selling higher-priced annual plans where the fee difference adds up.

Tips and tip jars#

How it works: a few small, optional in-app purchases ("small tip", "big tip") with no feature attached, or a thank-you screen after a milestone.

The rule: "Apps may use in-app purchase currencies to enable customers to "tip" the developer or digital content providers in the app" (App Review Guidelines, 3.1.1). Inside the app, tips for the developer go through in-app purchase like everything else.

Who it suits: free apps with a fond audience, open source apps, and apps whose developer is visible (a blog, a social account). Our read: tip jars rarely pay the rent on their own, but they cost almost nothing to add and give your biggest fans a way to say thanks. Pair a tip jar with an honest note about who builds the app.

Sponsorships#

How it works: one sponsor pays a flat monthly fee for a tasteful placement: a "supported by" line, a featured partner screen, or a slot in the app's newsletter.

Who it suits: niche apps with a well-defined audience that brands want to reach (a climbing app, a homebrewing app, a developer tool). Our read: a single relevant sponsor can out-earn an ad network in a small niche, because the sponsor is paying for the audience, not the impressions. It takes sales work, so treat it as a supporting stream once you have usage numbers to show.

Affiliate revenue#

How it works: the app recommends products and earns a commission when someone buys through its link.

Who it suits: apps whose job naturally involves a purchase decision: a gear checklist, a recipe app pointing to equipment, a travel planner. Our read: only recommend what you would recommend without the commission, and disclose it clearly in the app. If affiliate links start shaping the product, users notice.

Physical goods, services and B2B#

Apps that sell physical goods or real-world services (tickets, food, consultations) take payment through normal payment processors rather than in-app purchase; Apple's business models page lists free apps with physical goods and services as their own sub-type (Apple business models). And if teams or schools use your app, a separate business licence, sold by invoice on your website, can be worth more than all consumer revenue combined.

Which model fits your app? A decision table#

This is our editorial advice, based on how each model earns and on the sourced facts above.

Our read: if two models look equally good, pick the one you can explain in one sentence on your App Store page. Simple monetization converts better than clever monetization.

Our monetization stack for a solo developer#

This is the setup we would start with for a typical indie utility or lifestyle app on iOS and Android in late 2026. It is opinion, built on the prices checked today.

1. Store billing, done right#

• Join Apple's Small Business Program before your first sale.
• Enrol in Google Play's 15% service fee tier, which still applies to the first $1M in markets outside the US, UK, EEA, Australia and Japan. Google's help page says enrolment needs a payments profile, an Account Group and acceptance of the 15% service fee terms (Play Console Help).

2. A subscription layer you do not have to build#

You can write StoreKit and Play Billing code yourself, but receipt validation, entitlements across platforms, refunds and paywall tests eat weeks. These tools all have a free tier that covers a new app (prices from each vendor's own page, 9 Nov 2026):

Note the billing units differ. RevenueCat, Adapty and Qonversion measure tracked revenue; Superwall's paywall fee is on paywall-attributed revenue. RevenueCat's page does not say whether its 1% applies to all tracked revenue or only the amount above $2,500, so check before you model it.

Our read: pick one and stop shopping. At indie scale, the difference between these is a few dollars a month. The real cost is migrating later, so choose the one whose SDK and dashboard you like using.

3. A paywall with three options#

Monthly, annual (shown as the default, with the per-month equivalent) and lifetime. Add a free trial on the annual plan. RevenueCat's data on longer trials converting better is a reason to test a trial longer than three days, not a guarantee it will work for you.

4. A web checkout for US users and your own audience#

A Stripe checkout, or a merchant of record if you do not want to handle sales tax. Link to it from your website, newsletter and, where permitted, from the app.

5. A tip jar and a "remove ads" or "supporter" option where it fits#

Cheap to add, good for goodwill.

6. Analytics on the paywall, not just the app#

Track paywall views, trial starts, trial conversions, refunds and cancellations by plan. Your subscription tool's dashboard covers most of this.

Pricing and paywall placement#

What we would do (our read)#

• Show the paywall in onboarding, right after the user has seen the core value or set up something personal (a plan, a first entry, a first result). That is the moment intent is highest.
• Let people close it unless you have deliberately chosen a hard paywall. A soft paywall that reappears at natural limits (the fourth item, export, sync) converts later users without punishing everyone.
• Default to the annual plan and show the monthly equivalent. Make the monthly plan visible, not hidden; dark patterns cost you reviews and refunds.
• Explain the trial plainly: when it ends, what it will cost, and how to cancel. Apple's subscriptions guidance is worth reading before you design the screen.
• Price with your category, not your costs. Look at the ten apps your users also have installed. Price within that range unless you have a clear reason not to.
• Use local pricing in both stores. Both let you set or adjust prices by country.
• Test one thing at a time: trial length, then price, then plan layout. Changing three things at once tells you nothing.

What the sources say#

• Upfront asks convert better early: "Apps that ask for money upfront convert 5x better than freemium (10.7% vs. 2.1%)" (RevenueCat).
• Longer trials converted better in RevenueCat's data: "Trials of 17+ days convert 70% better than short trials (42.5% vs. 25.5%)" (RevenueCat).
• Introductory offers are limited: "Customers can redeem one introductory offer per subscription group" (Apple). Plan your offers so you do not burn the only intro offer on a weak first trial.
• A real indie example: Marco Arment's new app Unforgetful is "$19.99 per year (US)", "One subscription buys all platforms", and "There's a one-month free trial" (marco.org). One annual price, one long trial, every platform included: a clean example of a simple indie paywall.

A worked revenue example (illustrative)#

The numbers below are an example, not a forecast and not a benchmark. Every input is an assumption we chose to show the arithmetic. Swap in your own numbers.

The app: a habit tracker on iOS, in Apple's Small Business Program (15% commission), with a free trial on the annual plan.

Assumptions (ours):

• 3,000 new installs a month.
• 4% of installs become paying subscribers. (We picked a number between RevenueCat's freemium and upfront medians; your number could be far lower or higher.)
• Of those, 70% choose annual at $29.99 and 30% choose monthly at $3.99.

Month one, new subscribers:

• 3,000 × 4% = 120 new paying subscribers.
• 84 annual × $29.99 = $2,519.16
• 36 monthly × $3.99 = $143.64
• Gross: $2,662.80
• After Apple's 15%: $2,662.80 × 0.85 = $2,263.38 (before taxes Apple deducts and before your own income tax).

Subscription tool cost in that month (our arithmetic on published prices):

• RevenueCat: gross tracked revenue of $2,662.80 is just over the $2,500 free line. If the 1% applies to all tracked revenue, that is about $26.63.
• Superwall paywalls: $0, because paywall-attributed revenue is under $10k.
• Qonversion: $0, because tracked revenue is under $7,000.

What changes the result most: conversion and churn, not the store fee. Halve the conversion to 2% and month-one proceeds halve too. Monthly subscribers who cancel after two months contribute far less than the annual buyers. That is why the annual plan and the trial matter more than any fee optimisation.

The web checkout difference on one annual sale (our arithmetic):

• Through Apple at 15%: you keep $29.99 × 0.85 = $25.49.
• Through Stripe at 2.9% + 30¢ for a US domestic card: fee $0.87 + $0.30 = $1.17, you keep $28.82, before sales tax handling and before any commission Apple may be allowed to charge on linked-out purchases after the court remand.

The gap is real but modest at indie scale. Our read: build the web checkout for people who already come to your website, not as a reason to push every user out of the app.

Ads, the same way: ad revenue = impressions ÷ 1,000 × your eCPM. If your app shows 2 rewarded ads per user per week and you have 5,000 weekly users, that is 10,000 impressions a week. Multiply by the eCPM in your own AdMob dashboard. We are not filling in an eCPM because any number we invented would mislead you.

Common monetization mistakes#

1. Launching free and "adding monetization later". Users who arrived free resist a paywall that appears in an update. Decide the model before launch, even if the first price is low.
2. Copying a model from a different kind of app. A subscription that works for a fitness programme fails on a unit converter. Match the model to the usage pattern in the decision table above.
3. Interstitials in a productivity app. They earn little at small scale and cost you reviews. AdMob itself bans them on app load and exit (AdMob policy).
4. Not joining the Small Business Program. Paying 30% instead of 15% for no reason.
5. Burying the price. Unclear trials and hidden monthly plans lead to refunds and angry reviews. Say what it costs and when.
6. Too many plans. Monthly, annual and lifetime is plenty. Weekly plans, three tiers and add-ons confuse a small audience.
7. Lifetime priced too low. It quietly eats your annual revenue, and you keep serving those users forever.
8. Ignoring per-user costs. An AI app with unlimited use on a cheap plan can lose money on its best customers. RevenueCat's note that AI apps churn 30% faster is another reason to price for cost and retention, not just conversion.
9. Assuming a link-out is free. The US rules changed and the fee question is back in court. Re-check before you build pricing around it.
10. Optimising price before distribution. No paywall test matters with 40 installs a month. If you have no users yet, read how to market a mobile app with no budget first.
11. Selling or over-sharing data. It breaks Apple's guideline 5.1.2 consent rules and costs you the trust your revenue depends on.
12. Changing everything at once. Change trial length, price and layout in the same release and you will never know what worked.

The 30-day monetization plan#

This is our plan for a solo developer with an app that is live or close to launch. It assumes a few hours a day.

Days 1 to 5: decide#

• Write one sentence: "People pay for this app because ___." If you cannot finish it, your model is not clear yet.
• Place your app in the decision table and pick one main model and at most two supporting ones.
• List ten competing or adjacent apps with their prices and models.
• Enrol in Apple's Small Business Program and check your Google Play fee setup.
• Decide your free/paid line (what free users get, what paid users get).

Days 6 to 12: build the plumbing#

• Create your products in App Store Connect and Play Console: monthly, annual, lifetime (or your chosen set).
• Integrate a subscription tool (RevenueCat, Adapty, Qonversion or Superwall) or write StoreKit and Play Billing code directly.
• Build one paywall: three options, annual as default, a clear trial explanation, restore purchases and links to terms and privacy.
• Test purchases, restores, cancellations and refunds in the sandboxes on both platforms.
• If you use ads: set up AdMob, add rewarded ads only, and add a "remove ads" non-consumable.

Days 13 to 18: place the paywall#

• Put the paywall after the first moment of value in onboarding.
• Add soft paywall triggers at natural limits (an item cap, export, sync).
• Add a tip jar or supporter option if your audience is likely to use it.
• Set up events: paywall viewed, trial started, trial converted, cancelled, refunded.

Days 19 to 24: open the web channel#

• Add a pricing page on your website with the same plans.
• Set up a Stripe checkout or a merchant of record, and connect web purchases to app accounts.
• Decide, with today's guideline and fee status in hand, whether to link out from the US iOS app.
• Mention the web plan in your newsletter or community, where users are already outside the store.

Days 25 to 30: ship, watch, and plan the first test#

• Release the update with clear release notes about what is free and what is paid.
• Watch paywall views, trial starts and refunds every day for the first week.
• Reply to every review that mentions price, politely and quickly.
• Pick one test for next month: trial length, annual price, or paywall timing. One only.
• Plan your launch push. Our bootstrapped app launch guide covers where to announce.

How the models combine: three example setups#

These are our examples of how one main model and one or two supporting ones fit together.

Setup A: the utility. A one-time "Pro" unlock at a fair price, a free tier that is useful on its own, and a tip jar. No ads, no subscription. Revenue comes in bursts around launches and updates. Best for a developer who wants a simple, low-maintenance app.

Setup B: the habit app. A subscription with monthly and annual plans, a trial on annual, a lifetime option at a healthy multiple of the annual price, and a web checkout linked from the developer's newsletter. Revenue compounds as annual subscribers renew. Best for an app you plan to improve for years.

Setup C: the casual game. Free to play, rewarded ads for extra lives or hints, a "remove ads" non-consumable, and a few consumable packs. Revenue depends on how many people play and how often. Best for a game with short sessions and a strong reason to come back.

Notice what none of these do: stack every model at once. Each extra model adds code, support, review risk and decisions for the user.

Where ZeroRaised fits#

ZeroRaised is a launch directory for products built without institutional VC, including indie mobile apps. Once your paywall is live, submit your app for free and send your launch traffic somewhere that converts. For more guides on making money without investors, join the ZeroRaised newsletter.

Frequently asked questions#

What is the best way to monetize an app as an indie developer?#

For most utility and productivity apps, a subscription with an annual plan and a free trial, plus a one-time lifetime option, is the strongest default. Casual games with many short sessions usually do better with rewarded ads plus a paid "remove ads" unlock. Paid upfront apps work best for niche professional tools with a clear one-off job. Pick one main model, then add one or two supporting ones.

How much does Apple or Google take from in-app purchases?#

Apple's Small Business Program charges 15% on paid apps and in-app purchases for developers who earned no more than 1 million USD in proceeds; the standard subscription rate leaves you 70% in a subscriber's first year and 85% after one year of paid service. Google Play's service fee in the US, UK, EEA, Australia and Japan starts at 10% on your first $1M in annual earnings and on all auto-renewing subscriptions, plus a 5% billing fee when Google Play Billing processes the payment. Our app store fees guide has the full detail.

Can I link to my own website to take payments in a US iPhone app?#

Apple's App Review Guideline 3.1.1(a) says entitlements are not required for developers to include buttons, external links or other calls to action in their United States storefront apps. In December 2025 the Ninth Circuit said Apple may charge a commission on linked-out purchases tied to costs that are genuinely and reasonably necessary, and sent that issue back to the district court. Check the current guideline and our app store fees guide before you rely on a zero-fee link.

Do ads or subscriptions make more money for a small app?#

It depends on how often people open the app and how much they rely on it. Ads earn per impression, so they need lots of sessions. Subscriptions earn per paying user, so they suit apps people depend on every week. Run the arithmetic with your own AdMob eCPM and your own trial conversion before you choose; we do not quote typical eCPMs because they vary too much to be useful.

Do I need RevenueCat or a paywall tool to sell subscriptions?#

No, you can use StoreKit and Google Play Billing directly. A tool mainly saves time on receipt validation, cross-platform entitlements and paywall testing. RevenueCat is free up to $2,500 in monthly tracked revenue, Adapty is free under $5K a month, Qonversion is free at or under $7,000 a month, and Superwall's paywall product is free up to $10k in monthly paywall-attributed revenue.

Sources#

• Apple: Choosing a business model, last checked 9 Nov 2026
• Apple: App Store Small Business Program, last checked 9 Nov 2026
• Apple: In-App Purchase, last checked 9 Nov 2026
• Apple: Auto-renewable subscriptions, last checked 9 Nov 2026
• Apple: App Review Guidelines (3.1.1, 3.1.1(a), 5.1.2), last checked 9 Nov 2026
• Apple Developer Program, last checked 9 Nov 2026
• Android Developers Blog: Expanded billing choice and lower fees on Google Play, last checked 9 Nov 2026
• Play Console Help: Service fees, last checked 9 Nov 2026
• Play Console Help: Changes to Google Play's service fee in 2021 (15% tier enrolment), last checked 9 Nov 2026
• Play Console Help: Registration fee, last checked 9 Nov 2026
• AdMob Help: Payment thresholds, last checked 9 Nov 2026
• AdMob Help: Payments, last checked 9 Nov 2026
• AdMob Help: Rewarded ads, last checked 9 Nov 2026
• AdMob Help: Ad formats, last checked 9 Nov 2026
• AdMob Help: Disallowed interstitial implementations, last checked 9 Nov 2026
• RevenueCat: State of Subscription Apps 2026, last checked 9 Nov 2026
• RevenueCat pricing, last checked 9 Nov 2026
• Superwall pricing, last checked 9 Nov 2026
• Adapty pricing, last checked 9 Nov 2026
• Qonversion pricing, last checked 9 Nov 2026
• Stripe US pricing, last checked 9 Nov 2026
• Fenwick: Ninth Circuit Largely Upholds Ruling in Epic v. Apple, last checked 9 Nov 2026
• Marco Arment: Unforgetful, last checked 9 Nov 2026