RevenueCat vs Stripe is a question Apple has already answered.
Most RevenueCat vs Stripe comparisons open with fee tables and never reach the rule that decides the outcome. If your app unlocks a digital feature, a subscription or premium content inside iOS, Apple requires that purchase to run through in-app purchase. Stripe is not allowed to touch it. That one sentence removes the choice for most mobile subscription apps, and it is the first thing to settle before anything else in your app monetization strategies.
So this is not a shootout. It is a map of which product is legal where, what each one is built to do, what both vendors publish as their price, and the narrow set of cases where Stripe is not merely permitted but required.
Check which one your app is allowed to useThe short version
One of them moves money, the other sits on top of Apple and Google.
Stripe charges cards. It handles invoices, tax and recurring billing anywhere you are permitted to charge a card, which on iOS means your website and not your app. RevenueCat moves no money at all. It sits on top of a purchase the store already processed and answers one question for your app: is this person entitled right now.
The real question is therefore rarely which vendor to pick. It is whether Apple lets you out of in-app purchase for the thing you sell. If it does not, Stripe is off the table, and RevenueCat is competing with writing StoreKit yourself rather than with Stripe.
The guideline that settles it
App Store Review Guideline 3.1.1 is the whole argument, and it is not written ambiguously. If you want to unlock features or functionality within your app, you must use in-app purchase. The guideline names its examples so nobody can claim a grey area: subscriptions, in-game currencies, game levels, access to premium content, unlocking a full version. It then closes the detours, ruling out your own unlocking mechanisms and naming licence keys and QR codes among them.
The mirror image is guideline 3.1.3(e), goods and services outside of the app. If people buy physical goods or services consumed outside the app, you must collect those payments with a method other than in-app purchase, such as Apple Pay or ordinary card entry. Apple does not merely tolerate Stripe there, it requires something that is not StoreKit. A delivery app taking orders through in-app purchase is the violation.
One crack is worth knowing about. Guideline 3.1.1(a) covers linking out to a site you own to buy digital content, normally through an entitlement you apply for. The guideline now states that the entitlement is not required for apps on the United States storefront to include buttons, external links or other calls to action. In every other storefront the prohibition still applies, so the same build can be compliant in one storefront and rejectable in another.
Apple, App Store Review Guidelines, sections 3.1.1 and 3.1.3
Try it
Which one are you actually allowed to use
Three answers decide it, and not one of them is about fees.
Apple in-app purchase, no alternative
Guideline 3.1.1 requires in-app purchase to unlock features or functionality inside the app.
What each product is actually for
RevenueCat is a subscription layer. It wraps StoreKit and Google Play Billing, keeps receipt validation and renewal state off your servers, and gives your app one entitlement answer per user. It connects to the App Store, Google Play, the Amazon Appstore, Roku, Paddle, its own web billing product, and to Stripe. That last connection is the tell: a tool shipping a documented Stripe integration is not positioned as a replacement for Stripe.
Stripe is a payment stack. Cards, invoices, tax, hosted checkout, and Stripe Billing for anything recurring. On the web it does everything RevenueCat does and a great deal more, because it owns the transaction end to end. Inside an iOS app it owns nothing that guideline 3.1.1 covers, and no amount of SDK work changes that.
The pairing teams actually ship is both at once. Stripe on the website, store in-app purchase in the app, and one entitlement record spanning the two, so somebody who subscribed on your site opens the app already premium. If what you meant to compare was two subscription layers rather than a layer against a payment rail, revenuecat vs superwall is the comparison you were reaching for.
What each one charges, and what it charges on top of
RevenueCat publishes one number. You pay nothing up to 2,500 US dollars in monthly tracked revenue, then 1 percent of what you track once you pass that line, with a custom enterprise tier for high volume. The load-bearing word is track. That 1 percent is not a payment fee, because RevenueCat never took the payment. It sits on top of whatever the store already deducted.
Stripe splits its price into two lines. Card processing is one, and the rate varies by the card and the country it was issued in, so there is no single global number to quote. Stripe Billing, the recurring part, is a separate 0.7 percent of billing volume on the pay as you go plan, with cheaper committed monthly plans above it. Setting 1 percent against 0.7 percent compares unlike things, since only one of them stands behind Apple.
Behind Apple sits the number that dwarfs both. The App Store Small Business Program charges 15 percent on paid apps and Apple in-app purchases for developers who made up to 1 million US dollars in proceeds in the prior calendar year, and Apple applies its standard commission above that threshold. Measured against that, a 1 percent subscription layer is a rounding error, and a 0.7 percent one you are not permitted to use is no saving at all. Most of what looks like a pricing decision is a platform rules decision, which is why app store requirements belong earlier in the process than the fee comparison does.
RevenueCat pricing, free to 2,500 USD monthly tracked revenue then 1 percent
When Stripe is the right answer
Physical goods and services consumed outside the app. This is not a preference you get to weigh, it is guideline 3.1.3(e), and in-app purchase is not permitted for it. Marketplaces, bookings, deliveries, ticketing, hardware: a card method every time, and Stripe is a perfectly good one.
Web-first products with a mobile companion. If most subscriptions are bought on your site, Stripe takes the money and the app only reads entitlement. The same goes for anything sold business to business: invoiced annually, purchase orders, seat counts. None of that fits the StoreKit model, and Apple is not asking it to.
Everything else on iOS hits the same wall, so the honest next step is not choosing a vendor. It is getting the list straight of what Apple insists goes through its own billing for your product, then letting the architecture follow from it. Write the billing code first and you will rebuild it after the first rejection.
What each option actually gives you
| Option | iOS digital subscriptions | Web checkout | Receipts and entitlements handled | Published price |
|---|---|---|---|---|
| Store in-app purchase on its own | Yes | No | you build it | store commission only |
| RevenueCat over store in-app purchase | Yes | through its Stripe or web billing link | Yes | free to 2,500 USD MTR, then 1 percent |
| Stripe on its own | No | Yes | Yes | processing plus 0.7 percent Billing |
| Stripe plus RevenueCat | in-app purchase covers the iOS side | Yes | Yes | both fees, one entitlement record |
| Your own receipt server | Yes | No | you build and keep maintaining it | engineering time |
Building the billing into an app you own
The build is less about the vendor than about one decision: where the purchase happens. Native in-app purchase means products defined in App Store Connect, a paywall, receipt validation, restore purchases, and then the states nobody puts in a demo. Billing retry. Grace period. Refunds. Family sharing. Someone who upgrades halfway through a term. That list is what a subscription layer is really selling, and it is why people who start with a home-made receipt server tend to buy one within a year.
Newly is an AI app builder for the app around all of this. You describe what you want in plain English and it writes a real React Native and Expo project you own, runs it on a cloud iPhone or Android simulator while it builds, and uploads iOS builds to TestFlight with your own Apple Developer account. The Deploy tab has an Android section too: one press builds, signs and uploads to Google Play internal testing, and it also produces a standalone release APK you can install on a phone directly. Plans are $25 a month and there is no free plan. There are no built-in payments, so billing is something you or an SDK add. You pull the code with npm i -g @newly/cli and then newly pull with your project id, which is the point: whichever way this comparison lands, the StoreKit or Stripe integration lives in a codebase you control.
Where an off-the-shelf tool stops fitting is the moment your pricing stops being one subscription. Metered usage, seat counts, regional price points, a trial length that varies by channel, an annual plan sold on the web and consumed in the app: each is a data model question before it is a billing question. It is also why the entitlement record wants to live somewhere you can query, rather than being inferred from a receipt every time the app opens.
Questions people ask about RevenueCat and Stripe
Not for digital unlocks. Guideline 3.1.1 requires in-app purchase when you unlock features or functionality within the app, and it names subscriptions and premium content among its examples. You can still use Stripe on your own website, and under guideline 3.1.3(e) you must use a method other than in-app purchase for physical goods or services consumed outside the app.
Build the app first, then decide where the money lands
Describe what you are selling and who it is for, get a real project you own, and wire in whichever billing the platform rules actually leave you.
Start building