Create auto-renewable subscription products in App Store Connect and map them to RevenueCat offerings and entitlements so your iOS app can sell and unlock access reliably.
Configuring subscriptions with RevenueCat means keeping two systems in agreement: App Store Connect, where the actual products and prices live and where Apple collects payment, and RevenueCat, where you group those products into offerings and grant access through entitlements. App Store Connect is the source of truth for what a user can buy and what it costs; RevenueCat is the source of truth for what having bought it means in your app. The connective tissue between them is the product identifier, a string you define in App Store Connect and reference exactly in RevenueCat. If those identifiers ever disagree, products will not load and entitlements will not unlock. Understanding this division up front prevents most integration mistakes. RevenueCat never creates products in App Store Connect for you and cannot replace it; you always configure the products, pricing, and legal agreements on Apple's side first, then describe how to sell and interpret them on RevenueCat's side. Keeping this mental model straight also makes debugging faster later, because almost every failure is a disagreement between these two systems rather than a bug in your Swift code.
Before any paid product can load, your Apple Developer account must have the Paid Applications Agreement active in App Store Connect, with tax and banking information completed. This is the single most common reason products return empty even when everything else is correct, so handle it first. In App Store Connect, go to Business, sometimes labeled Agreements, Tax, and Banking, and confirm the Paid Applications Agreement shows as active rather than pending. If it is pending, you must accept the latest terms and supply the required tax forms and bank details for your legal entity; missing a single required field keeps the agreement inactive. Apple will not serve in-app purchase products to StoreKit until this is in place, and RevenueCat, which relies on StoreKit underneath, will therefore see nothing to sell. Newly signed agreements can also take time to fully activate, and Apple periodically issues updated terms that must be re-accepted, which can silently break a previously working setup. Getting this done at the start saves hours of confused debugging later when offerings mysteriously come back empty despite correct code and correct identifiers.
Auto-renewable subscriptions in App Store Connect live inside a subscription group, which represents a set of mutually exclusive options a user chooses among, such as monthly and yearly tiers of the same plan. In App Store Connect, open your app, go to the Subscriptions section under the Monetization area, and create a subscription group with a clear internal reference name and a customer-facing display name. Placing related durations in the same group is important because it lets users upgrade, downgrade, or crossgrade between them, and Apple prorates accordingly. Products in different groups cannot be exchanged this way, so plan your grouping around the choices you want users to make. A common structure is a single group named something like "Pro Access" containing a monthly and an annual subscription. If you sell distinct, non-competing subscriptions, such as two unrelated feature sets, those belong in separate groups. The group also controls the ranking of levels of service, which determines what counts as an upgrade versus a downgrade, so ordering your tiers thoughtfully now avoids awkward proration behavior later.
Inside your subscription group, create each subscription product. Give every product a unique product identifier, the string RevenueCat will reference, using a clear convention such as com.yourcompany.app.pro.monthly. Set the subscription duration, choose the price, and add at least one localization with a display name and description that App Review and users will see. You must also supply a subscription-specific review screenshot and any required metadata before the product can be approved. If you plan to offer a free trial or introductory pricing, configure that here as an introductory offer on the product, and remember that eligibility rules for introductory offers are enforced by Apple per subscription group. Save each product; newly created products often start in a state such as Missing Metadata or Ready to Submit, and they can take time to propagate to StoreKit. Record every product identifier exactly, because you will type these into RevenueCat and any mismatch, including a stray character or wrong case, breaks the mapping between the two systems. A tidy, consistent naming convention across all your products makes the later mapping step far less error-prone.
For RevenueCat to validate purchases and, in some cases, read subscription status server-side, it needs to communicate with Apple. In the RevenueCat dashboard, open your project's Apple App Store app configuration and provide the required credentials, which include your app's bundle identifier and an App Store Connect shared secret or an App Store Connect API key, depending on the current setup RevenueCat documents. The bundle identifier must match your Xcode project and App Store Connect record exactly. Providing an App Store Connect API key or shared secret allows RevenueCat's backend to validate receipts and receive App Store Server Notifications about renewals, cancellations, refunds, and billing issues, which is what keeps entitlement status accurate over time without the app being open. Follow RevenueCat's current app-configuration documentation for the exact fields, since Apple periodically changes how these credentials work and RevenueCat updates its guidance to match. This step links the two systems at the account level, complementing the per-product mapping you do next through offerings and entitlements. Skipping it can leave you with purchases that validate at the moment of sale but whose later lifecycle events never reach RevenueCat.
An entitlement in RevenueCat is the level of access your app checks for, deliberately decoupled from any specific product. Instead of asking "did the user buy the monthly product," your app asks "does the user have the pro entitlement," which stays true whether they bought monthly, annually, or on another platform. In the RevenueCat dashboard, go to the Entitlements section and create an entitlement with a stable identifier such as pro; this string is what you will reference in Swift with customerInfo.entitlements["pro"]. Then attach the App Store products that should grant this entitlement by adding each product identifier you created in App Store Connect. Both your monthly and annual products would attach to the same pro entitlement, so either purchase unlocks the same features. Keeping the entitlement identifier stable and human-readable matters because it is referenced directly in your app code; renaming it later means a code change and a coordinated release, so choose it carefully at the outset. A common mistake is adding a new product or duration later and forgetting to attach it to the entitlement, which produces a valid purchase that grants no access.
Offerings are how RevenueCat presents purchasable options to your paywall, and they let you change what you sell without shipping an app update. In the dashboard's Offerings section, create an offering with an identifier such as default, then add packages to it. Each package represents a choice on your paywall, like Monthly or Annual, and maps to one App Store product. RevenueCat provides standard package types, such as monthly and annual, plus custom identifiers if your durations do not fit the presets. Attach the correct App Store product identifier to each package so the SDK fetches its live price from StoreKit. Mark one offering as current; this is the one your app receives from offerings.current, which is what you typically render. Because offerings are server-driven, you can later run experiments, swap prices, or reorder packages from the dashboard alone, without an App Review cycle. Confirm each package points at the intended product before moving on, since a wrong mapping silently sells the wrong plan and is easy to overlook until a customer reports it. Offerings and entitlements are separate concepts: offerings decide what is shown and sold, entitlements decide what access results.
With agreements signed, products created, credentials connected, entitlements defined, and offerings built, verify that everything lines up before testing purchases. In the RevenueCat dashboard, confirm each offering's packages reference real, existing App Store product identifiers, and that each of those products is attached to the correct entitlement. In App Store Connect, confirm the products show a state indicating they are ready and that their identifiers match RevenueCat character for character. Then run your app with debug logging and call offerings() to confirm the packages load with correct localized prices, which proves StoreKit, App Store Connect, and RevenueCat all agree. Make a sandbox purchase with a sandbox Apple ID and check that the expected entitlement becomes active in the returned CustomerInfo. If products load but the entitlement never activates, revisit the product-to-entitlement attachment. If products do not load at all, revisit agreements, identifiers, and propagation timing. Verifying the full chain now prevents shipping a paywall that silently fails for real users, which is far more costly to discover after release than during a few minutes of deliberate testing.
You create the actual products, durations, and prices in App Store Connect, which is Apple's source of truth and where payment happens. In RevenueCat you only reference those products by their identifiers and organize them into offerings and entitlements. RevenueCat never creates App Store products for you.
An offering is what you show on your paywall, a set of purchasable packages mapped to App Store products. An entitlement is the level of access your app checks for after purchase, decoupled from any specific product. Multiple products can grant the same entitlement, such as monthly and annual both unlocking pro.
This usually means the purchased product is not attached to the entitlement in RevenueCat. In the Entitlements section, confirm each App Store product identifier that should grant access is listed under the correct entitlement, and that the identifiers match App Store Connect exactly.
Yes. Until the Paid Applications Agreement is active in App Store Connect, with tax and banking information complete, Apple will not serve in-app purchase products to StoreKit, so RevenueCat offerings will come back empty. Handle this before anything else.
Usually yes. Placing competing durations of the same plan in one subscription group lets users upgrade, downgrade, or crossgrade with proration. Put genuinely distinct, non-competing subscriptions in separate groups. In RevenueCat, both durations typically map to the same entitlement.