Hej -- so I’ve read several topics here about the best way to increase pricing of existing subscriptions in both iOS and Android, and wanted to make sure if I got this right, because it all feels very complicated for what should be a very common use case.
Let’s say we want to increase price from 1.99 to 2.99 for a monthly subscription, and 19.99 to 29.99 for a yearly subscription, both in the same “Subscription Group” in iOS, and in the same “Subscription” in Android.
We want to grandfather existing users; so ideally everybody paying 1.99 right now, will keep paying that amount until they cancel, and will still be able to upgrade to the 19.99 yearly subscription.
There seem to be two strategies:
Option 1:
Increase the price of the existing plans in the App Store and Google Play, choosing to keep the existing customers at the same price.
Pro:
- The “official” way -- easy to later let people opt-in / transition to the price change.
- Keeps the subscription groups simple.
- Offers etc still apply to the original subscription; no duplication
- By default if somebody unsubscribes for >60 days, they will need to onboard the new pricing scheme, which sounds reasonable.
- Easy to later increase/decrease pricing again if needed
Con:
- Can a user still switch to the “legacy” pricing of the yearly subscription? I think this is seen as a “crossgrade” so it will apply the new yearly fee of 29.99?
- When fetching the products from RevenueCat, it will show the price of 2.99 / 29.99, even to grandfathered users. The only way to remedy is to not show any pricing in the app for the current subscription and just link them to the subscription management page of the App Store? But how would you promote your up-/crossgrades, if you don’t have the current pricing of the subscription? Or use webhooks, keep a log of “last purchase price” per user and show that amount, assuming it will not change. This sounds like something RevenueCat should be able to provide in CustomerInfo/EntitlementInfo?
- When I want to offer some free months to a customer, be it through offer codes or an in-app promotion, is this seen as a “new subscription”, thereby cancelling the legacy pricing? This is really unclear.
Option 2:
Create a new Subscription Group, create a new Offering, and have a “hardcoded” switch based on the entitlement/subscription “originalPurchaseDate” in the app, to show either the legacy subscription group, or the new one
Pro:
- Pricing is consistent, so getting the products within the offering will show the prices correctly, even to existing users
- Monthly subscribers can still switch to the legacy yearly subscription because they are still both “active”
Cons:
- At least on iOS, an app user that is not paying attention can have an active legacy subscription, but instead of pressing “Restore purchases”, buy a new subscription, and both would be active at the same time as they are in two distinct Subscription Groups.
- Lots of duplication in offers, promotions, etc
- You can never bring legacy customers to the new subscription group, and will always have two sets of users. If you do this yearly, this will make things very complicated.
- Difficult to bring customers who have cancelled a year ago into the new pricing group, as they probably have a really old “originalPurchaseDate”.
- I’ve heard of apps being rejected in App Review due to “unreachable” subscription groups
Really curious to hear some recommendations, especially if this increase/decrease is need on a yearly basis.
