Building Rork Subscriptions Around RevenueCat Entitlements — Access Checks, Offering-Driven Paywalls, and Restore

Drive the paywall from Offerings to keep prices out of code

It's tempting to write "$9.99 / mo" straight into the paywall, but that's the product-ID problem again: every price change means resubmitting the app, and you can't do regional pricing. An Offering keeps the set and order of displayed products on the dashboard side; the app just fetches "the packages to show right now" and renders them.

// src/services/offerings.ts
import Purchases, { PurchasesPackage } from 'react-native-purchases';
 
export async function getCurrentPackages(): Promise<PurchasesPackage[]> {
  const offerings = await Purchases.getOfferings();
  // `current` is whatever you set as the active Offering in the dashboard.
  return offerings.current?.availablePackages ?? [];
}
 
export async function purchase(pkg: PurchasesPackage) {
  try {
    const { customerInfo } = await Purchases.purchasePackage(pkg);
    return { ok: true as const, customerInfo };
  } catch (e: any) {
    // The user just dismissing the sheet is a "cancel," not a failure.
    // Treat it as an error and you flash a red toast on every dismiss.
    if (e.userCancelled) return { ok: false as const, cancelled: true };
    return { ok: false as const, error: e };
  }
}

The paywall UI displays product.priceString directly. RevenueCat returns a string already formatted for the device locale and regional price, so you never assemble currency symbols or thousands separators yourself. Format it by hand and it will break the moment yen and dollars mix across regions.

// src/components/Paywall.tsx
import { useEffect, useState } from 'react';
import { View, Text, Pressable, ActivityIndicator } from 'react-native';
import { PurchasesPackage } from 'react-native-purchases';
import { getCurrentPackages, purchase } from '../services/offerings';
 
export function Paywall({ onPurchased }: { onPurchased: () => void }) {
  const [packages, setPackages] = useState<PurchasesPackage[] | null>(null);
  const [busy, setBusy] = useState(false);
 
  useEffect(() => {
    getCurrentPackages().then(setPackages).catch(() => setPackages([]));
  }, []);
 
  if (!packages) return <ActivityIndicator />;
  if (packages.length === 0) {
    // Zero packages is a sign of a setup gap. In sandbox, products that are
    // "waiting for review" come back empty — surface a message, don't hide it.
    return <Text>No plans are available right now. Please try again later.</Text>;
  }
 
  async function onTap(pkg: PurchasesPackage) {
    setBusy(true);
    const res = await purchase(pkg);
    setBusy(false);
    if (res.ok) onPurchased();
  }
 
  return (
    <View>
      {packages.map((pkg) => (
        <Pressable key={pkg.identifier} disabled={busy} onPress={() => onTap(pkg)}>
          <Text>{pkg.product.title}</Text>
          {/* Use priceString as-is. Never format the price yourself. */}
          <Text>{pkg.product.priceString}</Text>
        </Pressable>
      ))}
    </View>
  );
}

With this structure, a year-end change like "push a 3-day-trial annual to the front" is just a dashboard Offering switch — no resubmission. In production, that swap speed is what you feel.

A listener that distributes state across the app

Purchases and restores change state on screens other than the paywall. Calling getCustomerInfo per screen makes the timing inconsistent, so receive "CustomerInfo updated" in one place via RevenueCat's listener and hand it out through Context.

// src/providers/EntitlementProvider.tsx
import { createContext, useContext, useEffect, useState } from 'react';
import Purchases, { CustomerInfo } from 'react-native-purchases';
import { isPro, getCustomerInfo } from '../services/purchases';
 
const Ctx = createContext<{ pro: boolean; ready: boolean }>({ pro: false, ready: false });
 
export function EntitlementProvider({ children }: { children: React.ReactNode }) {
  const [pro, setPro] = useState(false);
  const [ready, setReady] = useState(false);
 
  useEffect(() => {
    let mounted = true;
    const apply = (info: CustomerInfo) => mounted && setPro(isPro(info));
 
    // Fetch once on launch, then subscribe to updates. Funneling everything
    // through this one path — rather than setPro from each call's return —
    // keeps you from losing track of where state changes.
    getCustomerInfo().then((info) => { apply(info); setReady(true); }).catch(() => setReady(true));
    Purchases.addCustomerInfoUpdateListener(apply);
    return () => { mounted = false; Purchases.removeCustomerInfoUpdateListener(apply); };
  }, []);
 
  return <Ctx.Provider value={{ pro, ready }}>{children}</Ctx.Provider>;
}
 
export const useEntitlement = () => useContext(Ctx);

The gating side knows nothing about products or RevenueCat; it reads only useEntitlement().pro. ready is separate so you don't confuse the launch-moment "not fetched yet" state with false (non-member). Confuse them and the paywall flickers for an instant on launch, and members read it as "I paid and it still shows up every time."

Restore isn't a feature, it's an obligation

Restore isn't a nice-to-have. The App Store review guidelines require it for non-consumables and subscriptions; if there's no "already purchased? tap here," you get rejected. The implementation itself is short.

// src/services/purchases.ts (continued)
export async function restore(): Promise<boolean> {
  const info = await Purchases.restorePurchases();
  return isPro(info);
}

Watch the result handling. restorePurchases can succeed yet leave pro as false if that user has no purchase history. Assume "restore succeeded = membership back" and pop a success toast, and you'll tell a never-purchased user "restored." Read the returned isPro and split the message.

async function onRestore() {
  const restored = await restore();
  Alert.alert(restored ? 'Your purchase has been restored' : 'No restorable purchase was found');
}

If your app has its own auth, tying purchases to the account with Purchases.logIn(yourUserId) is sturdier than restore — the Entitlement follows the user across devices once they sign in. Decide up front: anonymous → restore button, account-based → login sync. Pin one policy so you don't end up with both half-implemented and tangled later.

What actually bit me in the sandbox

These are the time sinks that the setup docs don't make obvious.

Offerings come back empty. Right after you create products, while App Store Connect shows "ready to submit / waiting for review," getOfferings().availablePackages returns an empty array. The code is correct, the UI shows nothing, and you go hunting in the SDK and lose a day. That's why the paywall above shows a message on an empty array — so this state isn't swallowed silently. First check that the Packages show green under "Offerings" in the RevenueCat dashboard.

Sandbox subscriptions renew absurdly fast. A production monthly renews and expires every few minutes in sandbox. It's by design and handy for checking renewal behavior, but it's easy to think "I just bought this and it already expired." During tests, watch the active/inactive transition of the Entitlement, not the absolute expiry timestamp.

A StoreKit Configuration File never reaches the server. Xcode's local StoreKit testing is convenient, but purchases don't route through Apple's sandbox, so they don't sync to RevenueCat's servers. To actually validate an Entitlement-based design, test on a real device with a sandbox Apple ID, not local StoreKit. I once chased "the listener isn't firing" here — the cause wasn't the code; the purchase never reached the server.

Android assumes license testers and an internal test track. On Google Play, sandbox purchases only work with an account registered as a license tester and a build promoted to the internal test track. A debug APK sideloaded directly won't process billing — that's almost always the cause.

One last thing to verify

Once it works, confirm exactly one thing. Grep every place that decides "may I show this premium feature" and make sure nothing gates membership except isPro or useEntitlement. If even one leftover checks a product ID directly, or a device flag set at purchase time, that spot alone will diverge on a price change or a device switch. Have you narrowed the access axis to a single Entitlement? How maintainable your billing stays comes down, in the end, to that.

I hope this helps anyone moving from a no-code base into app monetization lay a solid foundation.