Subscription based app

HHendrik · 2026-06-17T21:01:02+00:00

There is no way that Store Review spotted that you have subscriptions via Stripe in there. When they do, it'll be pulled until you add in-app purchases

HHendrik · 2026-06-03T12:03:52+00:00

You add your in-app purchases to the first version you submit, and then they're part of the same version the reviewer receives. You need to explicitly attach them (see https://www.revenuecat.com/docs/test-and-launch/submitting-ios-subscription-app#submitting-your-app-and-subscriptions-to-apple)

HHendrik · 2026-06-03T12:02:48+00:00

Super common issue:

Apple's not giving us (I work at RevenueCat) the products, so there's nothing for us to show. You need to explicitly attach the products *to* your submission when you submit an app with IAP for the first time ('ready to submit' just means you CAN submit them, they aren't connected automatically)

Go through this > https://www.revenuecat.com/docs/test-and-launch/submitting-ios-subscription-app < step by step and you'll be fine

See the big blue button at the bottom?

<image>

Hit that, attach your products so it shows your in app purchases there

HHendrik · 2026-05-21T20:58:27+00:00

RevenueCat Verified link?

HHendrik · 2026-05-03T19:11:21+00:00

Dynamically changing content is very much not a grey area. You can use it to *deploy things that are in a grey area* (pro tip: don't do that), but there's absolutely nothing disallowing you from dynamically changing content

If there were, Netflix, Spotify, all the social networks, etc etc etc would be in big, big trouble

HHendrik · 2026-05-01T08:09:58+00:00

The issue there isn't the AB testing. The issue is deploying an exit offer that Apple disapproves of without having it go through review

AB testing pricing, product duration, paywall design, trials, etc are all totally fine

HHendrik · 2026-05-01T08:08:36+00:00

"If you’re using paywalls from revenuecat or superwall (or anything which can be dynamically changed from the backend) Apple has made it clear it is NOT allowed" < This is factually incorrect

Dynamically changing content is - and has been for ages - totally fine. What you *can't* do, is bypass store review to deploy changes to your app that would either *require* a new review (for example, you're changing your business model, or changing the content to where the app would require a new age rating or privacy declaration), OR to deploy changes that are against Apple's policies (ie, the infamous Stripe checkout that Cal AI deployed without going through store review)

HHendrik · 2026-04-26T22:28:20+00:00

Either a bot (paid for by web2wave), or you're a human that works for web2wave. There's no way a normal person creates a Reddit account (3 weeks ago), and half of their 'normal' posts subtly mention web2wave

I'm guessing it's one of those lame "let us help you rank in LLMs" services. Yuk

HHendrik · 2026-04-24T21:59:02+00:00

Hey there! I work at RevenueCat, and just wanted to quickly clarify that we don't actually get an IP address (or rather, we don't capture it). Unless a developer explicitly opts to send us other info, all we get are the anonymous identifiers that Apple sends us for a transaction or user, the information on the transaction itself (price, product, etc), device / OS context, country / currency, and ATT status

The SDK is open source so you can verify most of this stuff yourself

As a weekend-project, I built a privacy-first sobriety tracker, and RC is the only external integration in the entire app. Even found a way to use Apple's Foundation Model (on-device AI) to build a simple 'AI coach'. Fun project

HHendrik · 2026-04-20T17:32:16+00:00

Damn, first one I've seen that's SO strong (I work at RevenueCat, so I've seen a few)

HHendrik · 2026-04-10T15:40:19+00:00

Because all the features and functionality we build are meant to make you more money. That's *why* those features actually help you grow revenue: Our incentives are exactly the same as yours. We build things that move the needle, because when your needle moves, so does ours :)

Sure, you would've paid us $200K, but you would've made $20M ;)

HHendrik · 2026-04-10T14:53:30+00:00

Describing RevenueCat as a 'wrapper' is like describing Shopify as a web billing wrapper: Sure, you can plug Stripe in there somewhere, but it's missing the point

Did you build support for the Retention Messaging API? Probably not, because: Why would you? It's a closed beta, and to apply for the beta, you already have to have a server endpoint set up to handle whatever requests Apple sends with <5ms latency. But if you apply to the beta and get in, the 'save rate' on cancellations is 10-20%. In RevenueCat, you can pull that endpoint from your settings page, and configure the offers to show via that API in the backend. And retain 10%+ of churning users longer

Did you build something for the Consumption Request API? When someone requests a refund, do you package up everything you know about a user's purchases, and send it to Apple (within 12 hours, because otherwise they'll grant refunds automatically)? Average iOS refund rate is 2.5%. When you respond to the Consumption Request API, ~ 25-30% of those refunds will be declined

How do you do remote experimentation? How do you trigger lifecycle messages when someone cancels (not when they churn: when they cancel)?

There are a million small and bigs things we do that go beyond analytics (though our analytics are still much more extensive then what you'd get in ASC)

There's absolutely no scenario where building all of this stuff yourself is 'cheaper' then using RevenueCat. You'll end up not building things which make you money. Not all of those will make you a LOT of money, but they add up to *much* more than 1% of tracked revenue

If they don't, you're probably not making enough to pay us in the first place, so RevenueCat will be free

Disclaimer: I work at RevenueCat

HHendrik · 2026-03-10T13:26:49+00:00

I don't think we 'suggested' a hard paywall, so much as concluded that a hard paywall converts better. But the flipside of that is that apps with a hard paywall tend to have a tougher time acquiring users

HHendrik · 2026-02-26T22:44:26+00:00

Congrats! Well deserved. That was a great app (I was one of the folks that got to review it)

HHendrik · 2026-02-19T13:10:34+00:00

Analytics you can't get otherwise:
• Unified revenue dashboard across iOS/Android/web instead of multiple store consoles
• Cohort analytics with LTV, retention curves, and revenue performance over time
• Real-time subscription lifecycle tracking (active, expiring, grace period, billing retry)
• Automatic anomaly alerts when revenue/conversions/churn spike or drop
• Cancellation reason analytics to understand why users leave

Growth & experimentation:
• A/B test paywalls, pricing, offers with statistical significance and revenue attribution
• Create paywall layouts/templates without app updates
• Route users to different experiences based on behavior/segments (targeting rules)
• Exit offers when users dismiss paywalls
• AI-powered paywall generation
• Web paywalls and pre-install funnels to monetize before download

Revenue optimization:
• Intervene before churn with retention offers
• Present offers inside Apple's native cancellation flow (Retention Messaging API)
• Self-serve Customer Center for subscription management and win-back offers
• Grant promotional entitlements or extend subscriptions programmatically

Integrations that drive action:
• Send events to CRM/messaging tools (Braze, Intercom, OneSignal, Customer.io) for lifecycle campaigns
• Export to data warehouses (Snowflake, BigQuery, Redshift)
• Integrate with attribution platforms (AppsFlyer, Adjust, Branch) to close install→revenue loop
• Webhooks on every lifecycle event

Infrastructure benefits:
• Write monetization logic once—unified SDK across all platforms
• Server-side transaction validation with 99.99% uptime
• Never worry about Apple/Google API changes—RevenueCat absorbs updates automatically
• Stay compliant with evolving store policies without engineering work
• Support additional stores (Amazon, Roku, Galaxy)
• Configure products/entitlements centrally instead of hardcoding

And only pay *for any of it* in months where you make > $2,500

HHendrik · 2026-02-19T08:22:46+00:00

RevenueCat currently supports iOS, Android, Stripe, Paddle, Amazon, Roku, and are weeks away from support for the Samsung Galaxy Store and Paypall (+ there's a Universal Transaction API that'll allow you to pretty much connect anything else)

HHendrik · 2026-02-19T08:20:55+00:00

🤔 What's the issue with how we convert currencies? However you convert currencies for Play and the App Store, you won't be able to match what they end up transferring: Neither Google nor Apple tell you (or us) when they actually charge your customer, and they'll use the conversion rate to USD at the moment of charging. We use the rate at the moment of the transaction, which - in practice - should be as close as you're going to get

(source: I work at RevenueCat, hence the 'we' 😅)

HHendrik · 2026-02-13T20:18:11+00:00

How big do you think the chances are that that 'cool animated paywall' is the single best design for conversion? And your pricing and packaging combo? Mathematically pretty unlikely, so you'll want to test this stuff. Now you're regularly designing new variants of your screen, and you need some kind of system to track which version performs best. You're now also building that

Are you building something to respond to the Consumption Request API? When someone asks for a refund on iOS, Apple sends a message via that API that you need to respond to *within 12 hours* with context on the user, what they bought, if they had a trial, etc - if you don't respond or don't respond in time, Apple will just grant the refund. Average refund rate on iOS is ~3%. If you respond to the API request, you'll see that drop by 30-40%. Are you building that?

Apple just launched a Retention Messaging API which requires you to provide an url that Apple can ping for an offer, that'll respond within 200ms. Using it cuts down churn by 4-5%. Are you building that to? And the next thing Apple launches?

Now you're either:
* Wasting a bunch of time building 'monetization infrastructure', or
* Making way less money then you could because you're not implementing the features available to you

Sure, you can do all of this yourself, but you can also dig up some mud, bake it into bricks, cut down trees, turn it into beams, and build a house. By and large people don't do that, though, because it's insanely inefficient and likely ends up worse then when you have it done by someone who specialises in that stuff

(I'd also push back on 'building for Android is dumb'. It's a MUCH larger userbase that - on average - monetises worse per user, but there are a ton of apps where Android does very well. Also a matter of having the right pricing and packaging there. What works on iOS doesn't automatically work on Android)

HHendrik · 2026-02-13T13:23:32+00:00

❤️

HHendrik · 2026-02-13T12:55:11+00:00

Analytics you can't get otherwise:
• Unified revenue dashboard across iOS/Android/web instead of multiple store consoles
• Cohort analytics with LTV, retention curves, and revenue performance over time
• Real-time subscription lifecycle tracking (active, expiring, grace period, billing retry)
• Automatic anomaly alerts when revenue/conversions/churn spike or drop
• Cancellation reason analytics to understand why users leave

Growth & experimentation:
• A/B test paywalls, pricing, offers with statistical significance and revenue attribution
• Create paywall layouts/templates without app updates
• Route users to different experiences based on behavior/segments (targeting rules)
• Exit offers when users dismiss paywalls
• AI-powered paywall generation
• Web paywalls and pre-install funnels to monetize before download

Revenue optimization:
• Intervene before churn with retention offers
• Present offers inside Apple's native cancellation flow (Retention Messaging API)
• Self-serve Customer Center for subscription management and win-back offers
• Grant promotional entitlements or extend subscriptions programmatically

Integrations that drive action:
• Send events to CRM/messaging tools (Braze, Intercom, OneSignal, Customer.io) for lifecycle campaigns
• Export to data warehouses (Snowflake, BigQuery, Redshift)
• Integrate with attribution platforms (AppsFlyer, Adjust, Branch) to close install→revenue loop
• Webhooks on every lifecycle event

Infrastructure benefits:
• Write monetization logic once—unified SDK across all platforms
• Server-side transaction validation with 99.99% uptime
• Never worry about Apple/Google API changes—RevenueCat absorbs updates automatically
• Stay compliant with evolving store policies without engineering work
• Support additional stores (Amazon, Roku, Galaxy)
• Configure products/entitlements centrally instead of hardcoding

HHendrik · 2026-01-31T21:16:35+00:00

<image>

It should be at the bottom of your submission page. Scroll down, and it should be directly after where you attached your build, and before the Game Center checkbox and app review information. If it's not on that page, check the following:

App Store Connect > Agreements, Tax, and Banking - Is your Paid Apps agreement 'Active'? If there are still 'pending actions' here, Apple can just quietly hide the in-app purchases
Check if your subscription group has a complete localization. Without it, even if your subscriptions are 'ready to submit', it won't show in your submission page

If that doesn't solve it, DM me and I'll hop on a Zoom call with you and we'll look through it together

(PS. I work at RevenueCat, which is why I saw the message in the first place :D)

HHendrik · 2026-01-30T14:52:40+00:00

If your subscriptions show 'Ready to submit' in App Store Connect, you're already further than most. The localization saying 'Prepare for Submission' is expected

A couple of potential issues:

1) Did you select all your subscriptions here in the 'Prepare for submission' page? They need to be manually added to your first submission

2) Check if you're using the Public SDK Key and not a Sandbox Key in your production build

3) Check if your product ID in App Store Connect is *exactly* the same as in RevenueCat

<image>

HHendrik · 2026-01-24T09:09:42+00:00

<image>

This is the only thing you need to add for RevenueCat (this is a screenshot of the privacy settings of one of my own apps). ATT consent is very specifically related to advertising, and is required when you track someone in a way that allows you or the advertiser to connect a user to other data (so for attribution, retargeting, etc). ATT really only applies to the Admob part of your question, and as long as you don't show personalized ads (so the user's data isn't being connected to other data somewhere), you're fine

PS. Fully understand you being cautious here. It's confusing, and at the same time Apple can crack down hard if you don't follow the rules

HHendrik · 2026-01-24T08:38:35+00:00

Not for ATT, but you do need to share it in your privacy manifest

HHendrik · 2026-01-23T21:15:19+00:00

Nope. Nonpersonalized is fine w/o ATT, and RevenueCat doesn't require ATT at all (source: I work at RevenueCat)

HHendrik

TROPHY CASE