Rork App Revenue Design: Where Ads and Subscriptions Eat Each Other

Getting the Skeleton Out of Rork

Once the line is decided, hand the design to Rork — not just "add monetization." Ask vaguely and you'll get a skeleton where ads and paywalls share a screen.

Build a wallpaper app. Follow this revenue design strictly.

[User tiers]
- Free: ads, standard resolution, limited categories
- Premium ($1.99/mo, $11.99/yr): no ads, 4K, all categories, sync

[Ad placement constraints — IMPORTANT]
- No ads on the list screen, detail screen, or download-complete screen
- Interstitials fire ONLY on the transition from download-complete back to the list
- Banner appears only at the bottom of the list screen

[Paywall constraints — IMPORTANT]
- Paywall appears only on the download-complete screen
- Never on the first download (3rd acquisition onward)

[Stack]
React Native + Expo / RevenueCat / react-native-google-mobile-ads
Entitlement ID is "premium". Ad visibility must derive from that entitlement and nothing else.

Mark the constraints as IMPORTANT and Rork bakes the placement rules into component boundaries. Generate once with the vague prompt and once with this one, then read both — the difference is obvious.

After generation, check one thing: does ad visibility flow from a single entitlement source? If isPremium is scattered as local state across screens, restore-purchase will leak somewhere. It always does.

Build RevenueCat Entitlement-First

Treat RevenueCat as "the subscription purchase SDK" and it will break on you later — when you add a plan, run a campaign, or introduce a one-time purchase. Conditionals metastasize through the app.

The right shape: the app reads entitlements only. The mapping from plans to entitlements lives in the RevenueCat dashboard.

// The single source of truth for the whole app
import Purchases, { CustomerInfo } from "react-native-purchases";
 
const ENTITLEMENT_ID = "premium";
 
export function useEntitlement() {
  const [isPremium, setIsPremium] = useState(false);
  const [ready, setReady] = useState(false);
 
  useEffect(() => {
    const apply = (info: CustomerInfo) => {
      // Never inspect plan names (monthly / annual / lifetime / campaign).
      // Which plan granted the right is the dashboard's concern, not the app's.
      setIsPremium(info.entitlements.active[ENTITLEMENT_ID] !== undefined);
      setReady(true);
    };
 
    Purchases.getCustomerInfo().then(apply).catch(() => setReady(true));
    Purchases.addCustomerInfoUpdateListener(apply);
  }, []);
 
  // Returning `ready` matters. Render ads before resolution and a paying
  // subscriber sees an ad flash by — which lands in your reviews.
  return { isPremium, ready };
}

On why ready exists:

getCustomerInfo() hits the network, so entitlements are unresolved for the first few hundred milliseconds after launch. During that window isPremium is false. Render your banner there and a paying subscriber gets a flash of advertising.

A flash is enough. To that user, the experience is "I paid and still got ads," and that's what the review will say. Hold the ad slot empty until resolution completes.

Put Restore at Launch, Not Behind a Button

Apple requires a restore button. But designing around the button loses users. Someone who just switched phones will not go spelunking through your settings screen.

// Attempt a silent restore at launch (no UI)
async function silentRestore() {
  try {
    const info = await Purchases.restorePurchases();
    return info.entitlements.active[ENTITLEMENT_ID] !== undefined;
  } catch {
    // Fail quietly. This is not a moment to show the user an error.
    return false;
  }
}

Keep the button for review compliance, but do the actual restoring at launch. The user just experiences "it worked on my new phone." That's the correct experience.

Move Receipt Verification Server-Side

Never unlock server-side capability based on the client's customerInfo. It's trivially forgeable.

Consume RevenueCat's webhook and record entitlements on your side.

// Webhook receiver on Cloudflare Workers
export default {
  async fetch(request: Request, env: Env) {
    const auth = request.headers.get("Authorization");
    if (auth !== `Bearer ${env.REVENUECAT_WEBHOOK_SECRET}`) {
      return new Response("unauthorized", { status: 401 });
    }
 
    const { event } = await request.json();
 
    // Only handle events that grant or revoke rights
    const GRANT = ["INITIAL_PURCHASE", "RENEWAL", "UNCANCELLATION", "PRODUCT_CHANGE"];
    const REVOKE = ["EXPIRATION", "BILLING_ISSUE"];
 
    const key = `entitlement:${event.app_user_id}`;
 
    if (GRANT.includes(event.type)) {
      await env.KV.put(key, JSON.stringify({
        active: true,
        expires_at: event.expiration_at_ms,
      }), { expirationTtl: 60 * 60 * 24 * 40 });
    } else if (REVOKE.includes(event.type)) {
      await env.KV.delete(key);
    }
 
    // Return 200 even for unknown events. Returning 500 makes RevenueCat
    // retry indefinitely, and the webhook can get disabled.
    return new Response("ok", { status: 200 });
  },
};

That last comment is the practical trap. If you 500 on event types you don't recognize, retries pile up until the webhook itself is switched off. Acknowledge everything; act on what you handle.

Treating BILLING_ISSUE as immediate revocation is a judgment call. Kill features because a card temporarily failed and the recovered user may not come back. If you rely on grace periods, restrict revocation to EXPIRATION alone.

Ad Revenue Turns on Spacing, Not Placement

Frequency capping implemented as "1 in every N actions" is common — and it punishes your most engaged users.

One-in-five means a user who taps five times in ten seconds gets a full-screen ad every ten seconds.

// Gate on both count AND elapsed time
const MIN_ACTIONS = 5;
const MIN_INTERVAL_MS = 120_000; // at least 2 minutes apart
const COLD_START_GRACE_MS = 90_000; // nothing in the first 90 seconds
 
let actionCount = 0;
let lastAdAt = 0;
const launchedAt = Date.now();
 
function shouldShowInterstitial(moment: Moment, isPremium: boolean): boolean {
  if (!canShowInterstitial(moment, isPremium)) return false;
 
  const now = Date.now();
  if (now - launchedAt < COLD_START_GRACE_MS) return false; // protect first impressions
  if (now - lastAdAt < MIN_INTERVAL_MS) return false;
  if (++actionCount < MIN_ACTIONS) return false;
 
  actionCount = 0;
  lastAdAt = now;
  return true;
}

COLD_START_GRACE_MS exists because the first 90 seconds after install decide whether your app survives.

A user who hits a full-screen ad on first launch deletes the app. Skipping that one impression buys you the probability that they open it again tomorrow.

When You Ask for ATT Changes Your eCPM

On iOS, App Tracking Transparency opt-in rates feed straight into eCPM, because they determine whether personalized ads can be served at all.

And opt-in rate moves a lot depending on when you show the dialog.

Fire it at launch and the user is asked to allow tracking before knowing what your app is. They decline.

import { requestTrackingPermissionsAsync } from "expo-tracking-transparency";
 
// Ask right after they've received value, with context
async function askTrackingAfterFirstValue() {
  const shown = await AsyncStorage.getItem("att_asked");
  if (shown) return;
 
  // Show your own pre-permission sheet first, then hand off to the OS.
  // The OS dialog is one-shot: a decline can only be undone in Settings.
  await showPrePermissionSheet({
    title: "About the ads you'll see",
    body: "This app stays free because of ad revenue. Showing more relevant ads is what keeps it that way.",
  });
 
  await requestTrackingPermissionsAsync();
  await AsyncStorage.setItem("att_asked", "1");
}

The OS dialog fires exactly once. Once declined, you can't get it back unless the user opens Settings themselves. So gate it behind your own explanation and only send through the users who are inclined to say yes.

If someone taps "Not now" on your sheet, don't burn the OS dialog. You still have a next time.

Mediation Doesn't Work Just Because It's On

Running multiple ad networks against each other raises eCPM, but switching it on isn't enough.

• Set eCPM floors — without a floor, cheap networks will happily fill every slot
• Split networks by geography — the strongest network in Japan isn't the strongest in North America
• Prune networks that never win — each additional network adds load latency, and latency costs you impressions

That third one gets missed. When someone adds eight networks and watches eCPM fall, the cause is almost always load delay eating the impressions themselves.

Paywall Conversion Is Timing, Not Copy

You can rewrite paywall copy indefinitely and barely move conversion. I've burned plenty of hours doing exactly that.

What moves is who you show it to, and when.

Define the Trigger With Behavior

type UserSignals = {
  sessionsCount: number;      // launches
  itemsAcquired: number;      // downloads or saves completed
  daysSinceInstall: number;
  lastPaywallAt: number | null;
};
 
const PAYWALL_COOLDOWN_MS = 1000 * 60 * 60 * 24 * 3; // 3 days
 
function shouldShowPaywall(s: UserSignals): boolean {
  // No track record of receiving value? No paywall.
  if (s.itemsAcquired < 3) return false;
 
  // One launch isn't enough to form an opinion.
  if (s.sessionsCount < 2) return false;
 
  // Don't re-ask someone who just declined. This drives uninstalls.
  if (s.lastPaywallAt && Date.now() - s.lastPaywallAt < PAYWALL_COOLDOWN_MS) {
    return false;
  }
 
  return true;
}

itemsAcquired < 3 does most of the work here.

Three downloads means the user has confirmed the app is useful to them. A first-time user is still evaluating, and dropping a price tag into that evaluation just hands them a reason to stop.

The cooldown matters too. Re-showing a paywall the day after a decline generates uninstalls, not revenue. Wait three days and let them collect more value in between.

Why to Lead With Annual — and What It Costs

Price annual 30–50% below the monthly equivalent and feature it prominently. That's the standard play, and it works: churn is structurally lower, LTV climbs.

But there's a cost. Leaning on annual slows your learning rate.

With monthly, a paywall change shows up in churn within weeks. With annual, it shows up in a year. While you're still iterating on price and plan structure, keeping a meaningful share of monthly is what lets you tell what actually worked.

My own preference: show monthly plainly until the product settles, then bring annual forward once the design is stable. Going annual-only from day one locks in a design you haven't validated yet, for twelve months.

What to Measure, and What to Ignore

The list of measurable things is infinite. People who watch all of them watch none of them.

Read ARPDAU and D7 retention as a pair. That alone adjudicates most ad experiments.

ARPDAU up, D7 down means the change borrowed against future revenue. Raise ad frequency and this is precisely the shape you'll see.

import analytics from "@react-native-firebase/analytics";
 
// Always log paywall IMPRESSIONS. Log only purchases and you have no
// denominator, which means no conversion rate.
async function logPaywallShown(trigger: string, signals: UserSignals) {
  await analytics().logEvent("paywall_shown", {
    trigger,
    items_acquired: signals.itemsAcquired,
    sessions_count: signals.sessionsCount,
    days_since_install: signals.daysSinceInstall,
  });
}
 
async function logPurchase(plan: "monthly" | "annual", price: number) {
  await analytics().logPurchase({
    currency: "USD",
    value: price,
    items: [{ item_id: `subscription_${plan}`, item_name: `${plan} subscription` }],
  });
}

Attaching behavior signals to paywall_shown pays off later. You can answer "did triggering at 3 downloads beat triggering at 5?" analytically, without shipping a code change.

Where People Get Stuck

Paying subscribers see a flash of advertising

You're rendering the ad slot before the entitlement resolves. Use the ready flag above and hold the slot empty until resolution. This one usually reaches you via a review — meaning the star rating already dropped.

Ads don't appear in production

Check for leftover test ad unit IDs and verify the AdMob app ID in app.json. Delivery is often throttled for 24–72 hours right after store approval, so give it time before debugging further.

Purchase completes but premium doesn't unlock

Confirm the key in customerInfo.entitlements.active matches the entitlement ID in your RevenueCat dashboard exactly. Swapped sandbox and production API keys are a frequent culprit.

Subscription rejected in review

Restore purchases, cancellation instructions, and links to Terms and Privacy Policy all belong on the paywall screen itself. Bury them in a settings sub-menu and you'll be sent back.

Wrapping Up

The first move in revenue design isn't adding ad units or polishing paywall copy.

Identify the single moment in your app where the user is most satisfied.

Never put an ad there. Reserve it for the paywall. Push ads into the lower-density time on either side of it.

The line follows from that. After that it's just watching ARPDAU and D7 retention as a pair, and moving carefully.

Rork hands you the skeleton in under an hour. Spend the time it saves on drawing this line.

I'm still working this out myself — the placement I believe in today may look wrong to me in six months. But this is what I can say with confidence right now. Thanks for reading.