How I Think About App Monetization Before Writing a Single Line of Code
I've watched a lot of solo iOS developers — including past me — spend months building something only to discover there was no realistic path to meaningful revenue. The app worked. Users liked it. It just... didn't make money.
The problem almost never turned out to be the code or the design. It was always that monetization was an afterthought.
So here's how I actually think about this now, and some hard lessons along the way.
The mistake I kept making
I used to pick an idea, build it, ship it, and then ask "okay, how do I make money from this?" That ordering is catastrophically backwards.
The App Store crossed $85B in annual revenue last year — but the distribution is brutal. A tiny number of apps capture most of that. The difference between apps that earn real money and apps that quietly die isn't code quality. It's whether the developer validated a monetization model before committing to the build.
I started flipping the process: find niches where users already pay, then build something to serve them better. It sounds obvious. It took me longer than I'd like to admit to actually do it consistently.
What actually drives revenue (the numbers that matter)
Before you can pick a monetization model, you need to internalize a few metrics:
ARPU (Average Revenue Per User) — the single most useful number for comparing monetization approaches
LTV vs. UAC — if your lifetime value doesn't exceed what it costs to acquire a user, nothing works long-term
Conversion rate — the % of free users who go paid. Even moving this from 2% to 3% is a 50% revenue increase with zero change to acquisition
The benchmark context that surprised me most: average freemium-to-paid conversion on iOS sits at1–5%. Top apps in high-intent categories (health, productivity, finance) hit 8–12%. If you're below 1%, it's almost never a pricing problem — it's an onboarding or paywall clarity problem.
Which category you're in matters more than you think
"What apps make the most money?" — gaming dominates by raw volume, but ARPU tells a more interesting story:
| Category | Typical ARPU |
|---|---|
| Casual games | $0.05–$2 |
| Dating | $5–$30+/month |
| Health & Fitness | $8–$20/month |
| Productivity | $3–$10/month |
| Finance | $10–$25/month |
A niche professional tool with 10,000 highly motivated users can out-earn a casual game with 1M installs. Niche users have specific pain, and they pay more to solve it.
The corollary: if your target category has structurally low ARPU, no monetization model saves you. This is worth knowing before you build.
The 6 models, and when each one actually makes sense
Subscriptions — Apple's preferred model, and my default starting point. Recurring revenue, 15% commission after year one (vs. 30%), and preferential App Store featuring. Best when users return multiple times per week and the app delivers compounding value. The risk: you have to keep delivering or they cancel.
Freemium — Most common structure on the App Store. Free tier with real value, paid tier with clear upgrades. Pros: low barrier, high download volume. Cons: requires a real conversion funnel and most users will never pay.
In-App Purchases — Best for gaming (consumable loops, cosmetics) and episodic content. A small percentage of "whales" can drive enormous revenue. Less predictable than subscriptions.
Paid Upfront — Declining, but not dead. Works for niche professional tools where users have a specific, one-time use case and strong word-of-mouth handles discovery. Hard to compete with free-to-try expectations otherwise.
Advertising — Needs volume to matter. Rewarded video has the best eCPM ($10–$30+ in Tier 1 markets) and users actually like it. Banner ads barely move the needle. Post-iOS 14 ATT, opt-in rates sit around 25–40%, which hit targeted ad revenue hard.
Hybrid (freemium + ads) — Underrated. Free users see ads, subscribers get ad-free. The "remove ads" offer for $2.99–$4.99/year converts surprisingly well because users have already experienced the friction you're selling them relief from.
My quick decision tree:
Users return daily/weekly? → Subscription
Gaming or discrete unlockables? → IAP
High-volume, casual use? → Freemium + ads
Niche professional, one-time use? → Paid upfront
How I estimate revenue before building
This is where I used to skip steps and pay for it later. Now I won't start a build without running this:
Projected Downloads × Conversion Rate × ARPU = Monthly Revenue
Example: 10,000 monthly downloads × 3% conversion × $8/month = $2,400/month.
Run conservative, base, and optimistic scenarios. If even the optimistic scenario doesn't justify the months you're about to spend, that's the most valuable thing you can learn — and you learned it before writing any code.
For competitor download estimation, App Store ratings counts are a useful proxy. Roughly 1–5% of users leave a rating, so a competitor with 10,000 ratings probably has somewhere between 200K and 1M downloads. Cross that with category ARPU benchmarks and you've got a rough revenue estimate for any competitor app.
I also use Niches Hunter for this — it tracks 40,000+ apps daily and gives me competition scores and revenue potential estimates for specific niches. Honestly the manual version of this research was taking me days; having it automated changed how fast I can validate ideas. But whether you use a tool or do it by hand, do the estimation.
The niche gap signal I look for
The most reliable signal that a niche is worth entering:
High search volume + weak top apps — Users are searching, but the best available solutions have mediocre ratings and haven't been updated in months
Under 500 reviews on the #1 result + 3.x star average — Underserved market
Same feature requests appearing across multiple competitor reviews — Validated product gap with built-in monetization signal
When you find a gap like this, you know three things before you build: what model works (someone's already proving it), what price users accept (competitor pricing is public), and what your product needs to do better to win users.
What I'd tell myself three years ago
Design monetization into the product from day one — not bolted on after launch. Your paywall, onboarding flow, and pricing structure are UX problems that deserve as much design attention as your core features.
And instrument everything from launch. ARPU, LTV, conversion rate, churn — you can't optimize what you don't measure. RevenueCat for subscription analytics, Mixpanel for event tracking. Set these up before you ship, not after.
Curious what others have found here: what's the biggest monetization mistake you made on your first (or second, or third) iOS app? And for those running subscription apps — what's your actual trial-to-paid conversion rate sitting at? I've found these numbers hard to come by outside of aggregate benchmarks.
