+2
Let’s suppose there is a subscription group with monthly and yearly product. Now a user purchases my monthly plan then should I allow users to view the paywall? Currently my approach is to let users know they already own the “Pro” package which doesn’t let them redirect to a paywall and because of that they can’t also see restore purchases button. So should i still separately show the restore puchases button? or keep following my current approach?
Best answer by Michael Fogel
View original
+6
Hey
I recommend checking out our document on managing subscriptions here which goes into more depth on how upgrades, downgrades, and crossgrades would go on the App Store.
We also have an in-depth guide on subscription groups and how certain flows work around them which can be found here.
As far as viewing the paywall goes, this is really up to you. If you know the user has an entitlement and its the only entitlement so you dont want to show them the paywall that is completely fine and really personal preference. The user would still be able to switch between monthly/yearly in settings and handle that crossgrade or upgrade outside of your paywall but a paywall might help them access that from your app.
As far as showing a restore purchase button, It is recommended that all apps have some way for users to trigger the restorePurchases method, even if you require all customers to create accounts. This is just incase something goes wrong and the user needs to access their purchase for some reason.
Hope that helps!
+2
Thanks for the help
+6
Even if user mistakenly redirects to paywall mistakenly showing available products, when user clicks subscription product the control goes to standard Apple IOS API showing message “you already subscribed to this product”. I tried ;)
In my simple application, I simply subscribe to events from Firestone such as “on authenticated”, “on Id change”, and callback will open paywall if user is not subscribed. If user s subscribed, callback will open product page. Super simple, and there is no way to explicitly land on “paywall” page, although there is some delay: user buys product, RevenueCat receives event, Firestone receives event from RevenueCat, client receives event from Firestone, callback checks event and redirects either to product page or to paywall. Too many intermediaries, but works acceptably fast for now, plus I can use Firestone claims in security rules which RevenueCat creates.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.