How to Monetize a React Native App in 2026: Ads vs Subscriptions vs One-Time Purchases

March 2026

How do you monetize a React Native app? After building and shipping over 10 apps, I've tried every model: ads with AdMob, subscriptions through RevenueCat, one-time purchases, and credit-based systems. The short answer is there are four real options, and the right one depends entirely on what your app does and how much it costs you per user.

Here's everything I've learned about React Native monetization from real apps with real (sometimes embarrassingly modest) revenue numbers.

Table of Contents

The Four Monetization Models

There are four ways to make money from a React Native app in 2026. Not ten, not twenty -- four that actually work for indie developers:

Each has a place. None is universally best. Let me walk through all four with the numbers I've actually seen.

Ads with AdMob

Google AdMob is the default ad network for mobile apps, and react-native-admob (now typically react-native-google-mobile-ads) is the standard library for React Native integration. Setup is straightforward: install the package, add your AdMob app ID, create ad units in the AdMob dashboard, and drop banner or interstitial components into your app.

The Numbers

Ad revenue is measured in RPM (revenue per 1,000 impressions). Here's what you can realistically expect:

• Most apps: $1-5 RPM for banner ads
• Finance and insurance niches: $10-20 RPM (these advertisers pay a premium)
• Interstitial ads: 3-5x higher RPM than banners, but users hate them
• Rewarded video ads: best RPM ($10-30), but only work in specific contexts like games

For a typical utility app with 1,000 daily active users showing a banner ad, you're looking at roughly $1-5 per day. That's $30-150 per month. Not nothing, but not enough to quit your job either.

When Ads Make Sense

Ads work when you have three things: a free app, high daily active users, and content that users browse frequently. Think weather apps, calculator apps, or simple games where users open the app multiple times per day and spend time on screens where ads can appear naturally.

The key word is "high DAU." You need thousands of daily active users before ad revenue becomes meaningful. If your app has 200 DAU, you're making coffee money.

The Honest Problem

Ads degrade user experience. Every banner takes up screen space. Every interstitial interrupts the user's flow. And the pay is genuinely terrible for most indie apps. I've run the numbers on several of my apps, and the conclusion was always the same: I didn't have enough users to make ads worthwhile, and showing ads to the users I did have would make the app worse.

For AI-powered apps specifically, ads are almost always the wrong choice. If each user interaction costs you money (API calls to OpenAI, image generation, etc.), you need revenue per user that exceeds your cost per user. Ad revenue of $0.003 per impression doesn't cover a $0.04 DALL-E generation.

Subscriptions with RevenueCat

Subscriptions are the best monetization model for most apps in 2026, especially anything involving AI features. RevenueCat handles the genuinely painful parts: receipt validation, subscription status tracking, trial management, grace periods, and cross-platform entitlements.

How Subscription Economics Work

The typical conversion funnel looks like this:

• Downloads to active users: 20-40% of downloads become weekly active users
• Active users to paid subscribers: 2-5% conversion rate is normal for indie apps
• Subscriber retention: expect 60-70% month-over-month retention for monthly plans, higher for yearly

Let me run real numbers. Say you have 1,000 daily active users and you offer a $9.99/month subscription:

• 3% conversion rate = 30 paying subscribers
• 30 x $9.99 = $299.70 gross revenue
• After Apple's 30% cut (15% if you qualify for the Small Business Program): roughly $210-255/month

That's not life-changing money, but it's real revenue that recurs every month and grows as your user base grows.

Pricing Strategy

I've seen three tiers work well for React Native apps:

• Weekly: $2.99-4.99/week. High revenue per user, but feels expensive. Works for apps people use intensely for short periods (fitness challenges, exam prep).
• Monthly: $4.99-12.99/month. The bread and butter. Most users who subscribe will pick this.
• Yearly: $29.99-79.99/year. Offer a significant discount over monthly (40-50% off) to lock in long-term subscribers. These users are your most valuable -- low churn, predictable revenue.

The yearly plan is where the real money is. A user paying $49.99/year is worth more than a user paying $9.99/month who churns after three months.

RevenueCat Integration

RevenueCat's React Native SDK (react-native-purchases) handles the entire subscription lifecycle. You configure your products in App Store Connect and Google Play Console, set up offerings in RevenueCat's dashboard, and then check entitlements in your app to gate features. The SDK handles receipt validation, subscription renewals, cancellations, and refunds automatically.

The biggest advantage of RevenueCat is the paywall experimentation. You can A/B test different prices, trial lengths, and paywall designs without shipping app updates. This matters more than most developers realize -- I've seen conversion rates double from changing paywall copy alone.

One-Time Purchases

One-time in-app purchases are the simplest model: user pays once, gets something permanently. This works for apps that deliver clear, bounded value. Think photo filter packs, premium themes, a "Pro" unlock that removes limits.

RevenueCat handles one-time purchases too (they call them "non-consumable" purchases), so you don't need a separate payment system.

When One-Time Works

One-time purchases are good for tool apps where the value is obvious and the cost of serving users is essentially zero after the initial purchase. A PDF scanner that works offline, a calculator with advanced functions, a design tool with premium templates.

The math is simple: you need to charge enough upfront to make the app viable. If your app costs $4.99 as a one-time purchase and you get 1,000 buyers, that's roughly $3,500 after Apple's cut. Not bad, but once sales slow down, there's no recurring revenue to sustain you.

The Downside

No recurring revenue means you're always on the treadmill of acquiring new users. You can't predict next month's revenue. And if your app has any ongoing costs (servers, APIs, content), you're paying those indefinitely from a one-time payment.

Credit and Token Systems

This is the model I wish I'd started with for my AI apps. A credit system works like this: give users a small number of free credits (enough to experience the app), then charge for credit packs. Each action in the app costs a defined number of credits.

Why Credits Work for AI Apps

The fundamental problem with AI apps is that every user action costs real money:

• A DALL-E image generation costs roughly $0.04-0.08 per image
• A GPT-4o API call costs about $0.01-0.03 per message depending on length
• Whisper transcription costs about $0.006 per minute of audio
• Video generation can cost $0.10+ per clip

With subscriptions, a power user who generates 500 images per month might cost you $20-40 in API fees while paying $9.99. You lose money on your most engaged users. With credits, every generation has a price, so your costs and revenue stay aligned.

How to Structure Credits

Here's a framework that works:

The hybrid model (subscription + credits) is what I've found works best. Subscribers get a generous monthly credit allocation, and heavy users can buy additional credits. This way you have predictable recurring revenue from subscriptions while never losing money on power users.

Implementation

A credit system needs a backend to track balances. You need to deduct credits before performing the action (not after -- if the API call fails, refund the credits). You also need to handle credit grants from purchases, which means connecting RevenueCat webhooks to your backend.

This is exactly what Ship React Native implements out of the box. The template includes a Convex backend with credit tracking, RevenueCat integration for purchasing credit packs and subscriptions, and the logic for granting credits on purchase. Setting this up from scratch took me weeks across my apps. Having it pre-built saves an enormous amount of time.

How Much Can a 1000 Downloads App Make?

This is one of the most common questions I see, and the answer varies dramatically by monetization model. Let's assume 1,000 total downloads with about 300-400 becoming weekly active users.

With Ads

If 300 daily active users each see 3-4 ad impressions per session at a $2-3 RPM:

• ~1,000 daily impressions
• $2-5 per day
• $60-150 per month

Realistically, for most apps with 1,000 downloads, ad revenue will be on the lower end. Maybe $30-50 per month. Enough to pay for your Apple Developer account and a coffee habit.

With Subscriptions

With 400 weekly active users and a 2-5% conversion rate at $9.99/month:

• 8-20 paying subscribers
• $80-200 gross revenue
• $56-170 per month after platform fees

At the higher end (5% conversion, good paywall, yearly plans), you could push this to $300-500/month. But 5% conversion requires a great app with a compelling value proposition and a well-designed paywall.

With Credits

Credit revenue depends entirely on your app's value proposition and usage patterns. An AI app where users regularly generate content might see:

• 10-15% of active users purchasing at least one credit pack
• Average purchase of $5-10
• $150-400 in the first month, declining unless you retain users

The advantage of credits is that revenue scales with usage, and your costs scale with usage too. If someone spends $20 on credits, you might spend $5-8 fulfilling those generations, keeping a healthy margin.

The Honest Truth

Most apps with 1,000 downloads make very little money. The difference between $50/month and $500/month isn't the monetization model -- it's whether your app solves a real problem that people will pay for. No payment model fixes a product problem.

Comparison Table

| Model | Best For | Revenue/1,000 Users | Setup Complexity | UX Impact |

|-------|----------|---------------------|------------------|-----------|

| Ads (AdMob) | Free utility apps, high DAU | $30-150/month | Low | Negative -- banners and interruptions |

| Subscriptions | SaaS-style apps, AI apps, content apps | $200-500/month | Medium | Neutral -- paywall is one-time friction |

| One-Time Purchase | Simple tool apps, offline apps | $500-3,500 total (not recurring) | Low | Minimal -- pay once, done |

| Credits/Tokens | AI apps, generation tools, API-heavy apps | $150-400/month (usage-dependent) | High | Positive -- users control spending |

When Each Model Is Wrong

Knowing when not to use a model is more valuable than knowing when to use it.

Don't Use Ads When...

• You're building a premium app. Ads signal "free and cheap." If you're charging for quality, ads undermine your positioning.
• Your app uses expensive APIs. If each user session costs you $0.05-0.50 in API calls, the $0.003 you earn from a banner ad doesn't even cover your costs. This was my exact problem with AIVidly.
• You have low DAU. Below 5,000 daily active users, ad revenue is negligible. Focus on building the user base first.

Don't Use Subscriptions When...

• Your app is a one-shot utility. If someone uses your app once to convert a file format or generate a single document, they won't subscribe. They'll download, use it, and delete it. A one-time purchase or credit system fits better.
• You can't deliver ongoing value. Subscriptions need to feel worth renewing every month. If your app doesn't give users a reason to come back regularly, they'll cancel after month one.

Don't Use One-Time Purchases When...

• Your app has ongoing API costs. This is the trap. You sell a $4.99 unlock, the user generates 1,000 AI images over the next year costing you $40-80 in API fees, and you've lost money. One-time purchases only work when marginal cost per user is near zero.
• You want predictable revenue. One-time purchases are spiky. You might make $500 one month and $50 the next. If you need to predict revenue for planning, subscriptions are better.

Don't Use Credits When...

• Your app doesn't have variable-cost actions. If every user costs you the same regardless of how much they use the app, credits add unnecessary complexity. A subscription is simpler and users prefer it.
• Your target audience isn't tech-savvy. Credits are a slightly more complex mental model. Some user demographics find "buy 100 credits" confusing compared to "subscribe for $9.99/month."

What I Learned from AIVidly and Newsletterytics

I've made most of these mistakes personally, so let me share what actually happened.

AIVidly: The Hard Lesson

AIVidly was an AI video creator app. Users described a concept and the app generated video content using AI. I originally launched it with a subscription model -- $9.99/month for unlimited generations.

The problem became obvious within the first month. Power users were generating dozens of videos, each costing me real money in API calls. A single heavy user could cost me $30-50/month in AI generation fees while paying $9.99. I was literally paying users to use my app.

I should have launched with a credit system from day one. By the time I realized this, I'd already set user expectations around "unlimited" access, and switching models mid-stream upset existing subscribers. The lesson: if your app has variable per-use costs, start with credits. You can always add a subscription tier later that includes a monthly credit allocation.

Eventually, I sold AIVidly because the unit economics never worked out at my scale. The buyer had a different cost structure and distribution strategy that made the app viable for them, but not for me as a solo developer.

Newsletterytics: Subscriptions That Worked

Newsletterytics was a newsletter analytics tool. The per-user cost was minimal -- it was mostly database queries, not expensive API calls. A straightforward subscription made perfect sense.

What worked: offering a free tier with basic analytics and a paid tier with advanced features. Users could see the value before paying. The conversion rate was modest (around 3-4%), but since my costs per user were nearly zero, every subscriber was profitable from day one.

The insight: the best monetization model is the one where your revenue per user reliably exceeds your cost per user. Sounds obvious, but I had to learn it the hard way with AIVidly.

Setting Up Monetization in Your App

If you're building a new React Native app and want monetization from the start, here's what I'd recommend:

Ship React Native includes all of this pre-configured: RevenueCat with subscription management, paywall components, and a complete credit system backed by Convex. The credit system tracks balances, handles purchases via RevenueCat webhooks, and deducts credits on API actions. Setting up monetization from scratch across iOS and Android took me weeks of debugging receipt validation, webhook handling, and edge cases. Having it already built and tested is the main reason I created the template.

If you're starting a new React Native app and you already know you'll need monetization, starting from a template that has it built in will save you a significant amount of pain. Whether that's Ship React Native or another boilerplate, don't underestimate how much time payment integration takes to get right.

The bottom line: pick the monetization model that matches your cost structure. If your app is free to serve, subscriptions. If every action costs money, credits. If you have massive traffic, maybe ads. And if your app delivers one-shot value, a one-time purchase. Get this decision right early, because switching models after launch is painful. I know from experience.