RevenueCat iOS: set up an in-app subscription

Why use RevenueCat instead of StoreKit alone

StoreKit, Apple's framework, lets you sell a subscription without any third-party service. But for a beginner, writing all the purchase, restore and access-check logic yourself means a lot of code to maintain, with edge cases that are easy to miss: switching devices, expiration, refunds.

RevenueCat sits between App Store Connect and your app: it reads your products, manages active subscriptions and saves you from writing that layer yourself. You stay in control of pricing and offers from a dashboard, without republishing your app every time you change something.

Step 1: create your products in App Store Connect

Before RevenueCat, the products have to exist on Apple's side. In App Store Connect, create a subscription group, then one or more levels with their duration, monthly or yearly for example, and their price per territory. Also fill in the text shown to users for each tier: Apple requires it before accepting the product in review.

A common miss at this stage: a product that's created but never submitted with its associated version in the app's first review. A pending product that was never included in an app submission stays invisible to your users, even if RevenueCat already sees it.

Step 2: connect RevenueCat to your app

In RevenueCat, you create a project, link your App Store Connect API key so RevenueCat syncs your products automatically, then define "entitlements," the access rights. An entitlement represents what the subscription unlocks, for example full access to the app, regardless of the exact product that triggered it.

This indirection is handy: if you change your offer structure later, say by adding a yearly tier, you just link the new product to the same entitlement, without touching the code that checks access in your app.

On the app side, the RevenueCat SDK for React Native installs in an Expo project with a dedicated plugin, and exposes a simple function to check whether the current user has an active entitlement.

Step 3: build your paywall

The paywall is the screen that presents the offer and triggers the purchase. RevenueCat offers paywalls you configure from the dashboard and can change without republishing the app, or you can build your own with the SDK if you want full control over the design.

Placement matters as much as design. A paywall shown before the person has seen the app's value usually converts worse than one placed right after a first successful action. The guide on iOS paywall mistakes for beginners covers the most common traps at this stage, beyond just the technical wiring.

Step 4: test purchase, restore and expiration

This is the step people rush the most, and yet it's the one Apple checks the most. Three scenarios must work before you submit:

Purchase. With a sandbox tester account, the purchase must unlock the entitlement immediately, and your app must react to that change without needing a restart.

Restore. On a new device or after reinstalling, with the same Apple account, a "Restore Purchases" button must find the active subscription. Apple systematically checks this flow in review, and if it's missing or broken, that's a common rejection reason under guideline 3.1.1.

Expiration. In the sandbox environment, subscriptions expire in a few minutes instead of several months, so you can check that access closes properly once the period ends, without waiting for a real billing cycle.

What RevenueCat doesn't replace

RevenueCat handles the purchase mechanics, not whether your listing or your paywall comply with guideline 3.1.2. It's still on you to describe the subscription correctly in your App Store description, state its exact price and duration, and provide your terms of use. The page on subscription vs. one-time purchase on iOS helps you pick the right model before you even get to this technical step.

RevenueCat also takes a cut of revenue above a certain monthly threshold, on top of Apple's commission on subscriptions sold in the app. Check their current tiers on their own site before building your business model around these two commissions.

The most common beginner mistakes

Forgetting the loading state. At launch, RevenueCat needs a brief moment to fetch the user's access rights. If your app shows paid content by default before that response, a user without a subscription can see, for a split second, content they haven't paid for. Plan an explicit loading state instead of an optimistic default display.

Checking access in the wrong place. An active entitlement should be rechecked every time a paid screen opens, not just once at startup. If the user cancels or their subscription expires while they're using the app, the next screen has to reflect that change.

Mixing up sandbox and production. Product identifiers and sandbox tester accounts are separate from production. A test that works in sandbox with the wrong Apple account, or a product created only in production, can give you the false impression that everything's ready.

A verified app, not just an app that compiles

A subscription that "works" in a quick test on your own account doesn't guarantee it survives a restore on another device or a real expiration. That's exactly what an Apple reviewer checks. The iOS in-app subscription page covers this whole chain, from creating products to the final check.

If you want to start from a base where the paywall and subscriptions are already in the code, that's what the starter code in the iOS Kit includes. To check your subscription the way the reviewer will, the Apple Review Kit brings together my pre-submission checklist and the notes to leave the tester for in-app purchases.

Frequently asked questions

How do you set up a RevenueCat subscription on iOS?

In four steps. First create your products in App Store Connect. Then connect RevenueCat with your App Store Connect API key and define your entitlements (the access rights), then build the paywall. Finish by testing purchase, restore and expiration: it's the step people often rush, and yet Apple checks it.

Is RevenueCat required to sell a subscription on iOS?

No. StoreKit, Apple's framework, lets you sell a subscription without a third-party service. But then you write all the purchase, restore and access-check logic yourself, with edge cases that are easy to miss: switching devices, expiration, refunds. RevenueCat sits between App Store Connect and your app to save you that layer.

What is an entitlement in RevenueCat?

An entitlement is an access right: it represents what the subscription unlocks, for example full access to the app, whatever the exact product that triggered it. If you add a yearly tier later, you just link the new product to the same entitlement. The code that checks access in your app doesn't need to change.

How do you test a RevenueCat subscription before submitting to Apple?

Three scenarios must work before you submit. Purchase: with a sandbox tester account, access unlocks immediately, without restarting the app. Restore: on a new device or after reinstalling, with the same Apple account, the restore button finds the active subscription. Expiration: in sandbox, subscriptions expire in a few minutes, so you can check that access closes.

Why is a product visible in RevenueCat still invisible to users?

Often because the product was never included in an app submission. A product created in App Store Connect but never submitted with its associated version in the first review stays invisible to your users, even if RevenueCat already sees it. It's a common miss at the product creation step.

Does RevenueCat take a commission on subscriptions?

RevenueCat takes a cut of revenue above a certain monthly threshold. It comes on top of Apple's commission on subscriptions sold in the app. Check the current tiers on RevenueCat's site before building your business model around these two commissions.