Adding Subscriptions to Your App: A RevenueCat and Paywall Guide

You decided your app needs a subscription. For most consumer apps that is the right call, because a subscription is the only revenue model that compounds instead of resetting to zero on the first of every month. The hard part is not the decision. The hard part is the plumbing between a tap on your paywall and money that lands in your account, across two app stores that each have their own rules, their own bugs, and their own idea of what a receipt is.

We build subscription apps at Codixus, and we ship our own portfolio of live App Store and Play Store apps on the exact same stack. So this is not theory. It is the setup we reach for on every new build, and the pile of mistakes we have watched founders make before they called us.

Why you should not hand-roll StoreKit and Play Billing

Your first instinct might be to go straight to the source. Apple gives you StoreKit. Google gives you the Play Billing Library. Both are real, documented, and free. So why pay for a middle layer?

Because taking the payment is maybe ten percent of the job. The other ninety percent is state. A subscription is not an event, it is a status that keeps changing over time while your app is closed. It renews at 3am. It slips into a billing-retry grace period because a card expired. The user asks Apple for a refund three weeks later. They reinstall on a new phone and expect their access back instantly. Every one of those is a state transition you now own, on two platforms, described with different vocabulary on each side.

The stores are honest about how much you are signing up for. Google says its billing system is the required path for selling digital goods on Android, and that a real integration pairs the on-device library with a backend that verifies purchases through the Play Developer API (Google Play Billing overview). Apple states that an auto-renewable subscription will "automatically renew at the end of their duration until the user chooses to cancel" (Apple auto-renewable subscriptions). Read those two lines again. The renewal and the cancellation both happen on the store's clock, not yours. You need a system whose entire job is to keep your record of who-has-access in sync with the store's record, forever.

That system is what RevenueCat is. It wraps both stores behind one SDK, holds the subscription state, and answers the only question your app cares about at runtime: does this user have access right now, yes or no. You can build that yourself. We have. It costs a real slice of your engineering budget on a problem that is already solved, and you will still be patching edge cases in production a year later.

The model you actually need to understand

RevenueCat has three concepts. Get these right and everything else falls into place.

Entitlements: what the user paid for

An entitlement is a level of access. RevenueCat defines it as "a level of access, features, or content that a user is 'entitled' to" (RevenueCat entitlements). Most apps need exactly one, call it "pro." Your code never checks product IDs or receipts, it checks whether the "pro" entitlement is active and gates the feature on that. This one indirection is why you can add a new price, a new plan, or a whole second store later without touching a single gate in your UI.

Offerings and packages: what you sell

An offering is the set of products you show on a paywall. A package groups the equivalent products across platforms, so your "annual" package points at the right iOS product and the right Android product without your app knowing the difference. The reason this matters commercially is control. Per RevenueCat, "if you've configured Offerings in RevenueCat, you can control which products are shown to users without requiring an app update," and changes "go into effect for all users right away" (RevenueCat offerings and packages). That means you can test a new price, swap the default plan, or run a promo from a dashboard instead of shipping a new binary and waiting on App Store review.

Wiring it into a React Native and Expo app

On our stack this is Expo and React Native with TypeScript, and the integration is the react-native-purchases SDK. You install it, add the config plugin so the native pieces land in your development build, and configure it once at startup with your public API key. From there, two calls carry almost the entire flow: fetch the current offering to render your paywall, and call purchase on the package the user tapped.

After any purchase, and on every cold start, you ask the SDK for the customer's info and read the entitlement. If "pro" is active, grant access. If not, show the paywall or the free experience. Do not store "isPro" in your own database and trust it forever. Treat the entitlement as the live answer, because it reflects a refund or an expiry that happened while the app was closed. Also ship a visible "Restore Purchases" button that re-syncs entitlements. Apple requires a restore path, and users on a new device will look for it.

Server-side truth: validation and webhooks

Client-side entitlement checks are enough to gate a screen. They are not enough to run a backend feature that costs you money, like an AI call or a server-rendered export. Anything expensive should be gated on your own server, and that server should learn about subscription changes from a trustworthy channel rather than believing whatever the phone sends it.

That channel is webhooks. RevenueCat "can send you notifications any time an event happens" as a POST to your endpoint, with the event as JSON, and your server signals success by returning a 200 (RevenueCat webhooks). You receive the initial purchase, each renewal, cancellations, billing issues, and refunds. On our builds a Bun service takes that webhook, verifies it, and writes the subscription state into Supabase Postgres. Now your backend has an authoritative record it can trust for access control, analytics, and win-back messaging when someone cancels. This is the piece founders skip and then regret, because without it your server is guessing.

Subscriptions are one of several ways to make money in an app. If you are still weighing the model itself, read our breakdown of mobile app revenue models before you commit to pricing.

Where the paywall goes, and when

The integration is the easy part. Placement is where the revenue is won or lost. A paywall shoved in a user's face before they have felt any value mostly teaches them to dismiss paywalls. A paywall that never appears mostly teaches them your app is free.

The version that converts is placed at a moment of earned intent. Let the user reach the result they came for, the finished edit, the answer, the win, and gate the next one or the premium version of it. Hard paywalls that block the whole app can work for a clearly premium product, but for most apps a value-first gate at the point of desire beats it. Because offerings are remote, you do not have to guess this once and live with it. Ship a sensible default, watch the conversion, and move the plan or the price from the dashboard. If you want a second set of hands on placement and the analytics, that is what our subscription app development service does. Book a 30-min studio call and we will look at your funnel.

The trial question, honestly

Free trials feel like a free win. They are not free. Apple supports a free trial as an introductory offer where "their subscription begins immediately, but they won't be billed until the offer duration ends," redeemable once per subscription group (Apple introductory offers). Two things follow from that. First, a trial converts to a paid renewal only if the user forgets to cancel or genuinely got value, and the store makes cancelling easy, so a weak product just donates a week of usage for nothing. Second, if your app calls a paid AI model or any per-use backend, every trial user is real cost with zero revenue attached until the trial converts.

Our default on cost-heavy apps is to launch without a trial, prove the paywall converts on its own, then test a short trial as an experiment. A trial is a lever, not a gift. Measure the paid conversion rate after the trial, not the sign-up rate during it.

Test in sandbox before you ship

Both stores give you a sandbox to run the full purchase loop with fake money. RevenueCat "automatically detects the environment (production vs. sandbox)," so no extra config is needed to test there (RevenueCat sandbox testing). Its guidance is worth repeating: test the flow, not the metadata, because stores often return wrong prices and product details in sandbox. Keep your checklist behavioral. Initiate a purchase, complete it, confirm the entitlement flips on, kill the app, reopen it, and confirm access survives. Then cancel and confirm access ends. If those pass in sandbox, your production flow will hold.

FAQ

Do I still need an Apple and Google developer account if I use RevenueCat?

Yes. RevenueCat sits on top of the stores, it does not replace them. You create your products and prices in App Store Connect and Google Play Console, then reference them in RevenueCat. The store still processes every payment and handles tax.

Is RevenueCat free?

It has a free tier that covers a meaningful amount of tracked revenue, with paid plans above that threshold. For an early-stage app it usually carries you well past launch. Check their current pricing page before you budget, since tiers change.

Can I add subscriptions to an Expo app without ejecting?

Yes. You do not use the old managed workflow, you use a development build with the config plugin, which lets native modules like react-native-purchases work while you keep the Expo tooling. This is the standard way to ship production Expo apps in 2026, and the setup we use for our own.

How long does a subscription integration take to build?

The wiring itself is days, not weeks. The time goes into product setup in both stores, paywall design, the server-side webhook handling, and sandbox testing across renew, cancel, and restore. On a Codixus build it lands inside the normal timeline with a TestFlight build on real hardware by the end of week two.

Need this built? Book a 30-min studio call. Tell us your app and your pricing idea, and we will map the paywall, the entitlements, and the backend before anyone writes code. Book a 30-min studio call.