← Back to blog

Setting up RevenueCat for an iOS app in 30 minutes

September 2025 · 7 min read

We use RevenueCat in every paid app we ship at mk0.net. The reason is simple: we don't want to write StoreKit receipt validation, refund handling, server-side trial tracking, and analytics one app at a time. RevenueCat's free tier handles the first $2,500 of monthly revenue per app. Here's how we set up new apps in about 30 minutes.

Why RevenueCat instead of bare StoreKit

Bare StoreKit 2 has gotten dramatically better. For a single product app, you can ship in-app purchase with about 60 lines of code. The reason we still reach for RevenueCat:

  • Cross-app entitlements (one paid user across multiple of your apps)
  • A consistent dashboard across apps for revenue analytics
  • Webhook automation that triggers on subscription state changes
  • Free server-side receipt validation with zero ops
  • Promotional offers and grace periods handled out of the box

Step 1: dashboard setup (5 minutes)

In the RevenueCat dashboard: create a project, add the iOS app with your bundle ID, paste your App Store Connect shared secret, then create your products in App Store Connect first (yes, you need that done before RevenueCat can pull them).

Define one entitlement called premium (or whatever you like). Attach all your products to it. The entitlement is what your app code checks; products are just SKUs.

Step 2: SDK install + offerings (10 minutes)

Add the RevenueCat Swift Package. Configure once at app launch:

Purchases.configure(
  withAPIKey: "appl_YOUR_KEY"
)

Then read offerings (the bundle of products you want to display): let offerings = try await Purchases.shared.offerings(). The dashboard's 'Current' offering is what most apps use; you can add others for A/B testing later.

Step 3: paywall integration (10 minutes)

Use RevenueCatUI's SwiftUI paywall view if you want a working paywall in 5 minutes; or build your own and call Purchases.shared.purchase(package:). We do the latter because we want full control of layout and copy.

Always include a 'Restore Purchases' button. App Review will reject without it. Wire it to Purchases.shared.restorePurchases().

Step 4: testing in sandbox (5 minutes)

In Settings → App Store, sign out of your real account and sign in with a sandbox tester (created in App Store Connect → Users and Access). Sandbox subscriptions renew aggressively - a 1-week subscription renews every few minutes - which is great for testing renewal flows.

Use StoreKit Configuration files (.storekit) for offline simulator testing. Even faster, but doesn't go through RevenueCat's server-side validation, so test sandbox at least once before shipping.

Step 5: going live (the actual checklist)

Before shipping the build:

  • Confirm your product IDs match between App Store Connect, RevenueCat, and your app code
  • Submit each subscription for review in App Store Connect (separate from your app submission)
  • Verify the entitlement check in your app behaves correctly when a sandbox tester is subscribed
  • Add server-side webhook listeners if you need to react to renewal/refund events (often not needed for indie apps)

What 30 minutes doesn't cover

Pricing, paywall design, free trial framing, and conversion optimization. Those are months of work. RevenueCat just gets the plumbing out of your way so you can focus on them.

See our paywall patterns post for the design side.