Once you’ve got an iOS subscription model running, analytics becomes a need. Which plan is how many people on? What’s the trial-to-paid conversion? What’s the churn rate? Cohort-based MRR?
Two options: a third-party SDK like RevenueCat or tracking it yourself on the backend. I’ve done both across my 12 apps. Here’s a practical comparison.
RevenueCat: pros and cons
RevenueCat is a SaaS for iOS + Android subscription management. On the iOS side it’s a StoreKit wrapper plus a dashboard.
Strengths:
- Setup in 30 minutes. Install the SDK, add App Store Connect keys, data flows in within a day.
- Pre-built dashboards. MRR, ARR, churn, retention, conversion, cohort analysis, LTV, revenue by country. All ready to go.
- Cross-platform aggregation. iOS + Android subscriptions in one dashboard.
- Automatic receipt validation. They do server-side validation with Apple. Security is handled.
- Paywall A/B testing. Their Experiments feature sets up A/B tests and reports on them.
- Webhooks. Subscription events fire webhooks into your own backend.
- Free tier: free up to $2500 MTR. At small scale, no cost.
Weaknesses:
- Dependency: you’re tied to a third-party service. If they’re down, your subscription flow has a problem.
- Pricing: paid above $2500 MTR. At $10K MTR it can run $500+/month.
- Vendor lock-in: hard to move off (all your user data lives in RevenueCat).
- Customisation limits: specific business logic is constrained.
- Extra SDK: the app binary grows by 500KB+.
Custom implementation
Keep subscription state on your own backend. Take events from StoreKit and process them server-side.
Setup:
- StoreKit 2 transaction listener (async stream)
- Send each transaction to the backend
- The backend runs receipt validation against Apple
- Write the user’s subscription state to the DB
- Receive Apple’s server-to-server notifications (ASSNs) on an endpoint
- Push the events into your analytics DB
Strengths:
- Full control. The code is yours, the behaviour is yours.
- No vendor dependency. Your own infrastructure.
- No monthly cost. Just hosting (AWS or otherwise).
- Custom business logic. Special rules, segmentation.
- Data privacy. User data doesn’t flow to a third party.
Weaknesses:
- Development time: 2 to 4 weeks to get it production-ready.
- Edge cases: Apple receipt-validation quirks, refund handling, grace period, family sharing, each one is its own headache.
- No dashboard: you have the data but no visualisation. You build it yourself or with Metabase, Retool, etc.
- Testing is painful: Apple’s sandbox environment is tricky. Test accounts, subscription-lifecycle simulation.
- Maintenance: when Apple changes StoreKit you have to update your code.
Decision criteria
Pick RevenueCat:
- Small team (1 to 3 people)
- MRR under $2500 at the start
- You need a dashboard fast
- You want A/B testing
- iOS and Android in parallel
- Cross-platform subscription management
Pick custom:
- Large scale ($10K+ MTR)
- You have an engineering team
- Custom business logic is critical
- Data privacy concerns (GDPR, special data handling)
- You want to avoid vendor lock-in
My pragmatic take
Most of my 12 apps are on RevenueCat. Why?
- I’m the solo developer on all of them
- Most are under $2500 MTR
- The dashboard is already there, building one would take weeks
- I run A/B tests (pricing experiments)
Parademi and GO HERO are at a bigger scale, and I still stay on RevenueCat, because migration is expensive and RevenueCat does the job.
If I built an enterprise-scale subscription platform (20K+ MTR), I’d consider going custom.
RevenueCat integration gotchas
If you’re going with RevenueCat, watch out for:
1. App User ID mapping. You have to send your own user ID to RevenueCat. Otherwise you get anonymous-user analytics.
Purchases.logIn(userId)2. Understand the entitlements model. RevenueCat uses “entitlements” instead of “products”. Names like “Premium” or “Pro”. You map products to entitlements.
3. Attribution data. Send install source and marketing campaign data to RevenueCat. Then you can run LTV-by-campaign analysis.
4. StoreKit 2 migration. RevenueCat supports StoreKit 2 now, but you may have to update legacy code.
5. Test environment: RevenueCat has its own sandbox. Production data stays separate.
Custom implementation gotchas
If you go custom, the edge cases to watch:
1. Receipt validation errors. Apple sometimes returns 500s, you need retry logic.
2. Introductory offer eligibility. Once per lifetime per Apple ID. Check it on the client, a mismatch fails the purchase.
3. Grace period handling. Payment failed, the user can still be premium for 3 to 16 days. The code has to handle it.
4. Family sharing. One family member buys, five members get access. Each has to be handled as its own “subscribed user”.
5. Refund webhook. Apple issued a refund (the user wasn’t old enough, wrong charge, whatever). Your backend has to find out and revoke premium.
Each one is a day of work. Two to four weeks total.
Analytics metrics that matter
Whichever you use, these are the metrics to watch:
1. Monthly Recurring Revenue (MRR). Monthly recurring revenue. The trend is what matters.
2. Conversion rate (install to paid). What percentage of trial-starters go on to pay.
3. Trial conversion rate. What percentage of trial users pay.
4. Churn rate. What percentage of subscribers cancel per month?
5. Customer Lifetime Value (LTV). How much does the average user pay in total before they leave?
6. Average Revenue Per User (ARPU). Average revenue per user per month.
7. Retention cohorts. What percentage of the people who subscribed in January are still active?
These seven are the baseline health check for a subscription. RevenueCat gives you all of them out of the box.
Hybrid approach
There’s a middle option: RevenueCat as primary, custom as supplementary.
- RevenueCat for subscription state and standard analytics
- Extra custom events in your own analytics (Mixpanel, Amplitude)
- Webhooks into your backend for custom business logic
This approach gives you RevenueCat’s value while keeping the door open for custom logic.
Migration strategy
You started on RevenueCat, you’ve scaled up, you want to move to custom. How?
- Dual write. Write to both RevenueCat and your own backend. 2 to 3 months in parallel.
- Data migration. Export historical data from RevenueCat. Import it into the custom backend.
- Feature parity check. Does custom produce the same dashboards as RevenueCat?
- Switchover. Make custom the primary, keep RevenueCat running as backup.
- Eventual removal. Six months in, remove the RevenueCat SDK.
That migration is a 3 to 6 month project. Plan for it in advance.
Takeaway
Subscription analytics is a critical topic. Get it wrong and you can’t see product growth or catch revenue leaks.
At small-to-medium scale RevenueCat is optimal. Quick setup, good dashboards, reasonable price. At large scale a custom implementation is worth considering, but it’s a serious investment.
Watch the metrics: MRR, conversion, churn, LTV. They’re the same whichever tool you use. The tool is the tool, the metrics are the target.