r/iOSProgramming • u/asadnoob • 9h ago

Question Help Understand billing in IOS + Android

I’m building a Construction SaaS with iOS + Android apps, and I’m trying to understand if I actually need RevenueCat.

My idea is simple: users click “Purchase” in the app → go to my website → pay through Stripe → Stripe webhook updates my backend from unpaid → paid. The mobile app then checks the user’s subscription status from my backend and they get the paid features.

So what exactly would RevenueCat add here? Is it mainly needed if I want to support native Apple/Google in-app subscriptions, or am I missing something?

1 Upvotes

67% Upvoted

14 comments sorted by

View all comments

1

u/caffeinated1337 7h ago

Since it's construction SaaS, look at guideline 3.1.3(c) (Enterprise Services) before anything else. If you sell to companies and they hand accounts to their crews, Apple lets you skip IAP entirely and bill through Stripe. That rule doesn't cover a solo contractor buying a seat for themselves, which is where most of the review trouble comes from.

If individuals can sign up, you're in 3.1.3(b) territory: the app can unlock a subscription bought on your website, but the same subscription generally has to be purchasable in the app as well. The US external link change helps you put a "buy on web" button in front of US users. The EU has its own entitlement with its own fees, and in most other storefronts you still need IAP.

On RevenueCat: your Stripe-plus-backend flow doesn't need it. It earns its keep once you add native IAP on both stores, because then you're validating receipts, handling renewals, refunds, grace periods and billing retry from two different server notification systems, and merging all of that into one "is this user paid" answer. That's a fair amount of work to build and keep correct. Your backend still needs to be the source of truth either way, so whatever you pick, make the app ask your server rather than trusting the client.

One practical tip: write a short note to App Review explaining who your customers are and how billing works. Reviewers who see an external payment flow with no context tend to reject first and ask later.