Mobile App Monetization Foundations With Rork — Choosing Between Ads, IAP, and Subscriptions

Implementing the Ad Model

For Rork apps, AdMob is the easiest entry point with detailed reporting.

// React Native + Rork AdMob example
import { BannerAd, BannerAdSize, TestIds } from "react-native-google-mobile-ads";
 
function AppScreen() {
  const adUnitId = __DEV__
    ? TestIds.BANNER
    : "ca-app-pub-XXXXXXXXXXXXXXXX/YYYYYYYYYY";
 
  return (
    <View style={{ flex: 1 }}>
      <YourMainContent />
      <BannerAd
        unitId={adUnitId}
        size={BannerAdSize.ANCHORED_ADAPTIVE_BANNER}
        requestOptions={{
          requestNonPersonalizedAdsOnly: false,
        }}
      />
    </View>
  );
}

Three implementation tips:

Pick the right format per slot. Banner (always-on, low yield), interstitial (full-screen at transitions, mid yield), rewarded (user-initiated, highest yield). My personal favorite is "rewarded ad to unlock a feature" — it usually wins on the revenue/UX trade-off.

No ads in the first minute. Showing ads immediately on first launch tanks reviews. Give users a 30-to-60-second grace period before any ad appears.

Throttle interstitials. Don't trigger on every screen change. Use rules like "every 3rd transition" or "at least 5 minutes since the last ad."

Lifting eCPM With AdMob Mediation

Once you've committed to ads, the biggest revenue lever is where the inventory comes from. AdMob works fine on its own, but wiring up mediation — bundling multiple ad networks — changes your eCPM (revenue per 1,000 impressions) even for the same number of impressions.

For years I've run AdMob as the mediation hub, bundling Meta Audience Network, Unity Ads, AppLovin, and Pangle. On one wallpaper app, moving from solo AdMob to mediation lifted rewarded-slot eCPM by roughly 1.4x. The mechanism is simple: when several networks compete for the same impression, the one bidding highest wins it.

The judgment call is waterfall vs. bidding. A waterfall assigns each network a fixed priority and price floor, querying them top-down. Bidding has all networks bid simultaneously and takes the highest. In practice I lean the main slots toward bidding to reduce missed fills, and keep only a few predictable secondary networks in a waterfall tail. An all-waterfall setup is easier to configure but stacks up query latency, stretching the time before an ad appears.

Knowing how eCPM "wobbles" also sharpens your revenue picture. In my observations, rewarded eCPM tends to run higher while North America is awake than during Japan's sleeping small hours, and the same app can swing monthly revenue by around 20% purely on its mix of serving countries. That's why I read reports not as a single total but as "country x format x time-of-day" — it shows which slots deserve more weight.

The numbers move with genre and season, so please read the ordering between formats rather than the absolute values. I initially tried to pile on rewarded ads because their eCPM was highest, nearly wrecked the UX, and later narrowed down to "opt-in slots users don't resent." Numbers tell you where to stop as much as where to push.

Implementing IAP

In React Native, react-native-iap is the standard library, paired with App Store / Play Store product setup and server-side validation. Rork templates make the bootstrap easy, but these three points are non-negotiable:

import { initConnection, getProducts, requestPurchase, finishTransaction, useIAP } from "react-native-iap";
 
const productIds = ["pro_unlock", "premium_pack", "feature_x"];
 
function PurchaseScreen() {
  const { connected, products, getProducts: fetchProducts, requestPurchase: doPurchase } = useIAP();
 
  useEffect(() => {
    if (connected) {
      fetchProducts({ skus: productIds });
    }
  }, [connected]);
 
  const handlePurchase = async (sku: string) => {
    try {
      await doPurchase({ sku });
      // Important: send the receipt to your server for validation
    } catch (err) {
      console.error("Purchase failed", err);
    }
  };
 
  return (
    <View>
      {products.map((p) => (
        <TouchableOpacity key={p.productId} onPress={() => handlePurchase(p.productId)}>
          <Text>{p.title} - {p.localizedPrice}</Text>
        </TouchableOpacity>
      ))}
    </View>
  );
}

Server-side receipt validation is mandatory. Trusting the client opens you to forged receipts and unauthorized unlocks. Use Apple's verifyReceipt API or Google's inAppPurchases.subscriptions.get API.

Always provide Restore Purchase. Without it, users who switch devices get the worst possible "I paid but it doesn't work" support ticket. It's also a frequent App Store rejection.

Optimize pricing per country. Japan ¥480 doesn't equal US $4.99. Use Apple/Google price matrices to set country-specific prices aligned with local purchasing power — this alone often lifts total revenue 1.3–1.5x.

Implementing Subscriptions

Subscriptions are a special case of IAP with more operational complexity. Three things I've found most important:

Free trial length matters. 3, 7, or 14 days produces meaningfully different retention. In my experience, "tools that need exploration" do best at 14 days; "content apps" do best at 7. 3 days tends to convert too few users.

const subscriptionId = "monthly_pro";
 
const handleSubscribe = async () => {
  try {
    await requestSubscription({
      sku: subscriptionId,
      // 7-day free trial (configure on the store side)
      andDangerouslyFinishTransactionAutomaticallyIOS: false,
    });
  } catch (err) {
    console.error("Subscription failed", err);
  }
};

Track expiration carefully. When a user cancels, they should keep Pro until the current paid period ends. Store expiresAt server-side and gate features on expiresAt > now.

Cancellation retention UI. A simple "if you cancel now you'll lose X; you'll keep Y until period end" panel before the cancel button can drop churn 10–20%. Small implementation, big impact.

Managing Subscription Churn With Numbers — Retention by Cohort

For subscriptions, the exit matters more than the entrance. The tool that helps most here is the cohort view: group users by the month they signed up and track how many stay over the following months.

On my workflow tool, trial-to-paid conversion runs around 30%, and month-two retention of users who cleared the first month sits just under 90%. The key is reading these two numbers separately. Low conversion points to a trial-experience or pricing problem; low post-first-month retention points to a hole in the value itself. Lumping them into "churn is high" leaves you with no clear move.

// Minimal example: N-month retention by signup-month cohort
type Sub = { userId: string; startedAt: Date; canceledAt: Date | null };
 
function retentionByCohort(subs: Sub[], monthsOut: number) {
  const cohorts: Record<string, { total: number; retained: number }> = {};
  for (const s of subs) {
    const key = `${s.startedAt.getFullYear()}-${s.startedAt.getMonth() + 1}`;
    cohorts[key] ??= { total: 0, retained: 0 };
    cohorts[key].total++;
    const boundary = new Date(s.startedAt);
    boundary.setMonth(boundary.getMonth() + monthsOut);
    // Counted as retained if not canceled by monthsOut later
    if (!s.canceledAt || s.canceledAt > boundary) cohorts[key].retained++;
  }
  return Object.entries(cohorts).map(([month, c]) => ({
    month,
    retention: c.total ? Math.round((c.retained / c.total) * 100) : 0,
  }));
}

Watching this cohort table month over month, you can see which signup month a price change or new feature started to move. Once, after extending the trial from 7 to 14 days, conversion rose a few points from that month onward — and I only became sure of it by lining the cohorts up. A single aggregate line would have been indistinguishable from seasonal noise.

Curbing churn isn't a UI-only job. Finding the "unused feature" common to low-retention cohorts and rebuilding it beats adding one more retention dialog. I'd rather use numbers as a map of where to work next than as a stick to beat myself with.

Legal/Compliance Essentials

For paid services in Japan (rules vary by jurisdiction):

Specified Commercial Transactions disclosure. Required: business name, address, contact, refund policy. Without it, store review may reject you.

Auto-renewal disclosure. Subscription must clearly state "when, how much, how to cancel" before purchase, per consumer protection guidance.

Children's app ad restrictions. Apps targeting under-13 audiences face significant ad limitations on AdMob. Misalignment between store age rating and ad config can lead to rejection or revenue stoppage.

Real Numbers From My Apps

Average monthly revenue across my live apps by model (2026):

Ads (10 wallpaper / wellness apps combined): ¥280,000/month / ~50,000 total DAU / ~¥5.6 per DAU.

IAP (one photo editing app): ¥95,000/month / 4,200 DAU / 2.8% conversion / ¥810/month ARPPU.

Subscription (one workflow tool): ¥134,000/month / 142 paying users / ¥944/month average.

Total around ¥500k/month — down from peak ¥1.5M but still "lives off this" territory. The structural advantage of running all three models is resilience: when ad CPMs drop, IAP and subscription absorb the impact.

Closing Thought

The most important monetization decision is "which model fits my app first." "Add everything" looks easy but is actually the hardest choice. Use the framework above to commit to one primary model, prove it works, then layer additional models if needed.

If you do one thing today, write down your app's expected DAU, retention rate, and differentiation strength on paper, then pick which of the three models fits best. If it's hard to decide, start with ads — it's the lowest-risk option.

For the next step into specific tactics for breaking ¥100k/month, the companion piece Real Strategy for Reaching ¥100k+/Month From a Solo Mobile App walks through the implementation and operations of revenue tuning experiments I actually ran on Rork-built apps.