⟐ Business/2026-04-28Intermediate

Choosing a Revenue Model for Your Rork App — Ads, Subscriptions, or One-Time Purchase, Backed by Real Operating Numbers

Drawing on the period when my wallpaper apps hit peak ad revenue, I rebuilt the comparison of ads, subscriptions, and one-time purchases under identical conditions — with genre-by-genre guidance and implementation notes for Rork.

rork⁵⁸ monetization⁴⁷ admob⁴ subscription²⁸ revenue-model app-store¹⁵ google-play⁵ indie-dev¹¹ rork-max⁴⁰ revenuecat²

✦ Premium Article

There was a stretch of time when I would open the AdMob dashboard late at night and line up eCPMs by country. The same wallpaper app earned two to four times more per impression in the US than in Japan. Bid prices rippled by hour of day, and toward month-end the numbers would float upward as advertisers burned through budgets. Even during the peak — when ad revenue crossed ¥1.5M in a month — I watched those figures sink to nearly half the next month. The lesson that a business should never depend on a single revenue model was burned into me in front of that dashboard.

Now that Rork lets you build apps this quickly, every project hits the same fork in the road at the planning stage: ads, subscription, or one-time purchase? What my own operating experience tells me is that the right answer shifts with genre and scale, while the clearly wrong patterns stay remarkably consistent. In this piece I rebuild the three-model comparison under identical conditions and walk through genre fit and the practical details of implementing each model in Rork.

The Character of Each Model — Where Revenue Comes From, and Where It Plateaus

Ad-based apps are free to use, monetized through impressions. Download volume is the revenue base, which pairs well with genres that pull strong store search traffic. The flip side: revenue per user is low, and placement design that respects the user experience is what keeps the model alive.

Subscriptions collect recurring payments directly from users. Margins are high, and once the base accumulates, month-over-month revenue becomes far more predictable. The cost is a standing obligation to keep shipping reasons to stay subscribed — and a long-running battle with churn.

One-time purchases ask users to pay once. Implementation is the simplest of the three and entitlement state is trivial to manage. But revenue depends entirely on new acquisition; when downloads flatten, so does income.

News apps and mini-game collections lean toward ads. Daily-use productivity tools lean toward subscriptions. Single-purpose utilities lean toward one-time purchases. That is the broad map — but as the projections below show, the optimal answer moves as your app grows.

The Reality of Ad Revenue (AdMob) — eCPM, Fill Rate, and Mediation

Two metrics govern ad revenue: eCPM (revenue per 1,000 impressions) and fill rate (the share of ad requests actually served).

Japanese eCPMs run roughly $0.50–$2.00 depending on genre — games higher, utilities lower. North America and Western Europe run $2.00–$8.00; Southeast Asia $0.20–$0.80. In my own portfolio, the regional mix of users moved revenue more than almost anything else. I prioritized English localization over new features at one point precisely because raising the price of the same impressions beat adding functionality on ROI.

Picking the Ad SDK — expo-ads-admob No Longer Works

Older tutorials still show expo-ads-admob, but that package has been removed from the Expo SDK and will not run today. For AdMob in an Expo project generated by Rork, the current standard is react-native-google-mobile-ads. It does not work in Expo Go, so a development build via EAS Build is a prerequisite.

npx expo install react-native-google-mobile-ads

{
  "expo": {
    "plugins": [
      [
        "react-native-google-mobile-ads",
        {
          "androidAppId": "ca-app-pub-xxxxxxxx~xxxxxxxx",
          "iosAppId": "ca-app-pub-xxxxxxxx~xxxxxxxx"
        }
      ]
    ]
  }
}

Placing Rewarded Ads Well

Rewarded ads convert well because users opt in. For mini-games, the classic placement is a "watch an ad for +100 coins" button on the score screen. For productivity tools, the same mechanic becomes "use a premium feature once for free."

Here is the implementation against the current API. Two habits prevent most production incidents: wait for the load event before showing, and unsubscribe your listeners.

// Rewarded ads with react-native-google-mobile-ads
import { useEffect, useState } from 'react';
import { TouchableOpacity, Text } from 'react-native';
import {
  RewardedAd,
  RewardedAdEventType,
  TestIds,
} from 'react-native-google-mobile-ads';
 
// Replace with your own ad unit ID in production
const adUnitId = __DEV__ ? TestIds.REWARDED : 'YOUR_REWARDED_AD_UNIT_ID';
 
const rewarded = RewardedAd.createForAdRequest(adUnitId);
 
export const RewardAdButton = ({ onReward }: { onReward: (n: number) => void }) => {
  const [loaded, setLoaded] = useState(false);
 
  useEffect(() => {
    const unsubLoaded = rewarded.addAdEventListener(
      RewardedAdEventType.LOADED,
      () => setLoaded(true)
    );
    const unsubEarned = rewarded.addAdEventListener(
      RewardedAdEventType.EARNED_REWARD,
      (reward) => {
        onReward(reward.amount); // e.g. +100 coins
      }
    );
    rewarded.load();
    return () => {
      unsubLoaded();
      unsubEarned();
    };
  }, [onReward]);
 
  return (
    <TouchableOpacity
      disabled={!loaded}
      onPress={() => {
        rewarded.show();
        setLoaded(false);
        rewarded.load(); // preload the next one
      }}
    >
      <Text>{loaded ? 'Watch an ad for +100 coins' : 'Loading…'}</Text>
    </TouchableOpacity>
  );
};

Interstitial Frequency — What a Policy Warning Taught Me

Interstitials carry the highest eCPMs and tend to become the revenue backbone, but careless placement risks both churn and policy enforcement. I once overlooked an implementation path that could fire a full-screen ad on nearly every navigation, and AdMob sent me a policy violation warning. I scrambled to fix it the same day — once ad serving is limited, revenue heads to zero immediately. Frequency control belongs in code, enforced mechanically.

My rule of thumb: a minimum time gap since the last ad, and at least two user actions in between. One small class enforces both.

// Interstitial frequency management
class AdFrequencyManager {
  private lastAdTime = 0;
  private actionCount = 0;
  private readonly minIntervalMs = 60_000; // at least 60s
  private readonly minActionsBetweenAds = 2;
 
  canShowInterstitial(): boolean {
    return (
      Date.now() - this.lastAdTime > this.minIntervalMs &&
      this.actionCount >= this.minActionsBetweenAds
    );
  }
 
  recordAction(): void {
    this.actionCount += 1;
  }
 
  recordAdShown(): void {
    this.lastAdTime = Date.now();
    this.actionCount = 0;
  }
}
 
export const adManager = new AdFrequencyManager();

At my peak, interstitials produced most of the revenue and banners contributed roughly a tenth as a supplement. Even then I never set the interval below 60 seconds. The higher an ad format's eCPM, the faster overexposure destroys the asset that produces it.

Build Mediation in the Console — Don't Bid on the Client

Mediation — stacking multiple ad networks — is the single most reliable eCPM lever. My stack ran AdMob as the anchor with Facebook Audience Network, Unity Ads, AppLovin, and Pangle layered in; compared to AdMob alone, eCPM improved by 30–50% in practice.

One caution: do not try to implement network selection in app code. Like many developers, I was once tempted to fetch bids from each network client-side and compare them — a pseudo-waterfall. It is the wrong shape both for latency and for policy. Today's AdMob configures mediation groups in the console, and bidding happens server-side. Your only client-side task is adding each network's official adapter as a dependency; the ad request code is identical to the single-network case.

# Adding adapters (one official adapter per network)
npm install react-native-google-mobile-ads
npm install @react-native-admob/admob-mediation-unity
# Then register each network in your AdMob mediation group in the console

✦

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN

✦A realistic monthly revenue model comparing ads, subscriptions, and one-time purchases at MAU 5,000 — plus the two classic estimation traps (daily vs. monthly mix-ups, confusing MAU with new installs) and how to correct them

✦Field-tested AdMob insights from running a four-network mediation stack, country-level eCPM swings, and the ad-placement safety rules I adopted after receiving a policy warning

✦How to choose between Rork (Expo) and Rork Max (Swift) for billing implementation, and how the Small Business Program cuts store fees from 30% to 15%

Secure payment via Stripe · Cancel anytime

✦

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

Unlock all articles with Membership →

Subscriptions — Retention Decides Everything

The appeal of subscriptions is lifetime value, but without an ongoing reason to stay, users quietly leave. In my view the model stands on three legs:

Premium features must be "can't work without it," not "nice to have" — nice-to-have gets cancelled at renewal
At least one meaningful update per month — a stalled subscription product is itself a cancellation reason
A free trial that demonstrates real value — three to seven days is standard

Pricing and the Power of Annual Plans

In the US App Store, $2.99 / $4.99 / $9.99 per month map to light, standard, and premium tiers; in Japan the equivalents are ¥480 / ¥980 / ¥1,980.

Always ship an annual plan, priced at eight to ten months of the monthly rate. To users it reads as a discount; to you it is upfront cash plus twelve months of churn immunity. At 8% monthly churn, the average monthly subscriber survives about a year — annual subscribers simply cannot churn during that window. If even 20% of converts choose annual, revenue stability changes visibly.

On Rork (Expo), RevenueCat Is the Practical Answer

For React Native subscriptions, wrapping StoreKit 2 and Google Play Billing with react-native-purchases (RevenueCat) is today's standard, and it especially pays off for solo developers: receipt validation, restores, and platform differences are handled for you. In an Expo environment, note that EAS Build is required.

// Subscription skeleton with RevenueCat
import Purchases, { LOG_LEVEL } from 'react-native-purchases';
import { Platform } from 'react-native';
 
export async function initPurchases(userId: string) {
  Purchases.setLogLevel(LOG_LEVEL.INFO);
  Purchases.configure({
    apiKey: Platform.OS === 'ios' ? 'YOUR_RC_IOS_KEY' : 'YOUR_RC_ANDROID_KEY',
    appUserID: userId,
  });
}
 
export async function purchaseMonthly() {
  const offerings = await Purchases.getOfferings();
  const pkg = offerings.current?.monthly;
  if (!pkg) throw new Error('No offering configured');
  const { customerInfo } = await Purchases.purchasePackage(pkg);
  return customerInfo.entitlements.active['premium'] !== undefined;
}
 
export async function isPremium(): Promise<boolean> {
  const info = await Purchases.getCustomerInfo();
  return info.entitlements.active['premium'] !== undefined;
}

The Trial-to-Paid Flow

Conversion is decided by the experience during the trial. The flow I have found effective:

Open the core features for free right after install
Use the first attempted access to a premium feature as the trigger to offer the trial
Two days before the trial ends, notify honestly: "billing starts soon"
On the final morning, send a recap of the premium features they actually used during the trial

Step 3 looks like it should hurt conversion, but it wins over the long run. The one month of revenue you keep from an unintended charge costs far more in store reviews and refund rates — that is where I landed. Apple and Google are also getting stricter about deceptive subscription flows every year.

One-Time Purchase — The Value of Simplicity, and Its Ceiling

One-time purchase means picking an App Store pricing tier and unlocking features in-app. Entitlement is a single bit: purchased or not.

It suits single-purpose utilities (barcode scanners, unit converters), self-contained games, education and reference content, and design tools. It pairs poorly with anything that incurs ongoing server costs — sales stop, costs don't.

Price and purchase volume are not linearly related. Overlaying my experience with market data, the pattern looks like this:

Price	Downloads (relative)	Monthly revenue estimate (1,500 new installs/mo)
$1.99	100%	$90–180
$4.99	50%	$110–220
$9.99	20%	$90–180
$19.99	8%	$70–120

Because volume falls steeply as price rises, utilities usually maximize revenue in the $2.99–$4.99 band. If you are unsure, start there and measure elasticity with sales.

Revenue Projections Under Identical Conditions — Realistic Numbers at MAU 5,000

This is the heart of the piece: the same app, three models, one set of assumptions. I should say upfront that most projections you find online — including the earlier version of this very article — contain two classic errors, and correcting them changes the picture substantially.

Error 1: Mixing daily and monthly. "DAU 3,000 × 8 impressions = 24,000" is one day of impressions. Feed it into a monthly revenue formula and you undercount ad revenue thirty-fold.

Error 2: Confusing MAU with new installs. "5% of MAU 5,000 converts to the subscription every month" implies the same users convert again and again. Conversions come from new installs.

The assumptions:

MAU: 5,000 / DAU: 3,000 / new installs: 1,500 per month
Ads: 8 impressions per DAU, eCPM $1.50 (Japan-centric audience)
Subscription: $3.50/month equivalent (¥480), 8% of new installs start a trial, 35% of trials convert, 8% monthly churn
One-time: $3.99, 3% of new installs purchase
FX: $1 = ¥150
Store fee: 15% (assuming the Small Business Program, below)

The Ad Model

Daily impressions: 3,000 × 8 = 24,000
Monthly impressions: 24,000 × 30 = 720,000
Monthly revenue: (720,000 / 1,000) × $1.50 = $1,080 ≈ ¥162,000

AdMob's share is already baked into eCPM, so no store fee applies. Net: about ¥162,000/month. The old version of this article reported ¥5,400 here — that is what the daily/monthly mix-up does.

The Subscription Model

Trials started per month: 1,500 × 8% = 120
Paid conversions per month: 120 × 35% = 42
Steady-state subscriber base: 42 / 0.08 (monthly churn) = 525
Steady-state monthly revenue: 525 × ¥480 = ¥252,000
After 15% store fee: ≈ ¥214,000

Net at steady state: about ¥214,000/month. But steady state takes time — on this growth curve you reach roughly 60% of it after a year, and the first month nets under ¥20,000, far below the ad model. Subscriptions are a test of whether you can survive the waiting period, financially and psychologically.

The One-Time Model

Purchases per month: 1,500 × 3% = 45
Monthly revenue: 45 × $3.99 = $179.55 ≈ ¥27,000
After 15% store fee: ≈ ¥23,000

Net: about ¥23,000/month, fixed at that level unless new installs grow.

Side by Side

Metric	Ads	Subscription	One-time
First-month net	≈ ¥162,000	≈ ¥17,000	≈ ¥23,000
Steady-state net	≈ ¥162,000	≈ ¥214,000 (after 1–2 years)	≈ ¥23,000
Implementation effort	Medium	High	Low
UX burden	High	Low	None
Revenue predictability	Low (eCPM swings)	High	Medium

The ¥162,000 for ads assumes eCPM holds at $1.50. As I described at the start, eCPM swings with seasons and advertiser budgets. Given the gap between my peak months and what followed, I plan ad revenue at about 70% of recent actuals — that is the margin of safety I trust.

Projections That Use a 30% Fee Are Out of Date

At indie scale, store fees are no longer 30%. Apple's App Store Small Business Program drops the commission to 15% for developers under $1M in annual proceeds, and Google Play takes 15% on the first $1M (as of June 2026 — both have application steps and conditions, so check the latest official terms). Compared to an old 30% projection, net revenue on the paid models shifts by more than 20%. Before you model subscriptions or one-time pricing, confirm your eligibility first.

Hybrid Design — Free-with-Ads Plus a Subscription

In practice, the strongest configuration is usually a hybrid: free-with-ads alongside a subscription that removes ads and unlocks premium features. Users who will never pay still monetize through ads; your heaviest users consolidate into the subscription. Leakage is minimized on both ends.

// Access control for the hybrid model
import { isPremium } from './purchases';
 
const BASIC_FEATURES = ['core-editing', 'export-jpg'];
 
export const FeatureAccess = {
  async canUseFeature(featureId: string): Promise<boolean> {
    if (await isPremium()) return true;
    return BASIC_FEATURES.includes(featureId);
  },
 
  async shouldShowAds(): Promise<boolean> {
    return !(await isPremium());
  },
};

Three design rules matter here. First, never weaponize the ad experience to push subscriptions — an app whose ads feel hostile gets uninstalled before it gets upgraded. Second, surface the premium pitch at the moment of feature access; a banner buried in settings goes unread. Third, offer a standalone "remove ads" one-time purchase (around $2.99–$5.99). The segment that resists subscriptions but will pay once to remove ads is larger than most developers expect.

Implementing on Rork vs. Rork Max

Finally, how this maps onto the Rork product line. As of June 2026, standard Rork (from $25/month) generates Expo (React Native) projects, while Rork Max ($200/month) is a separate product that generates native Swift apps. The billing paths are entirely different.

On Rork (Expo): every code sample in this article applies as-is. Ads via react-native-google-mobile-ads, subscriptions via react-native-purchases. Both include native modules, so they will not run in Expo Go — use EAS Build development builds. When adding the ad SDK to a freshly generated Rork project, remember the app.json plugin entry and a rebuild.

On Rork Max (Swift): you can use StoreKit 2 directly. Product.purchase() and Transaction.currentEntitlements cover the essentials, and receipt validation is built into the framework as transaction signature verification — for a small app, skipping RevenueCat entirely is a reasonable call. For ads, integrate the native iOS Google Mobile Ads SDK.

// Subscription purchase via StoreKit 2 on Rork Max (Swift)
import StoreKit
 
func purchaseMonthly() async throws -> Bool {
    guard let product = try await Product.products(for: ["premium_monthly"]).first else {
        return false
    }
    let result = try await product.purchase()
    if case .success(let verification) = result,
       case .verified(let transaction) = verification {
        await transaction.finish()
        return true
    }
    return false
}

The choice also reads through a revenue-model lens. If ads will carry the business, Rork (Expo) ships to both stores and maximizes total impressions. If subscriptions will carry it and you want to live deep in the Apple ecosystem — widgets, Live Activities — Rork Max has the stronger pitch.

Migrate in Stages — The Order I Recommend

After years of running apps solo, my honest take is that designing the perfect revenue model upfront is a poor use of time. Migrate in stages instead:

Validation (under 1,000 MAU) — implement ads only and confirm retention holds. At this scale, a subscription build-out lacks the sample size to even measure
Growth (1,000–5,000 MAU) — run on ad revenue while adding the subscription, and measure trial-start and conversion rates against real users
Transition (over 5,000 MAU) — once your measured numbers clear the projection lines above, make the subscription primary and demote ads to a free-tier supplement

As a concrete next step, look up your app's monthly new-install count. Every projection in this article can be rebuilt from that single number. Once you habitually think in new installs rather than MAU, revenue-model discussions become realistic almost overnight.

If you are standing at the same fork, I hope these numbers give you a firmer place to stand.

Thank You for Reading

Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.