I wanted to pick up on this older closed ticket if that is ok.
I am also running into this issue, and my offering is made of multiple packages/products like in the rc example / documentation here.
I am looking for custom metadata at the product or package to be able to put the “1 MONTH” and “1 YEAR” text somewhere. Even the “SAVE 38%” should be in custom data no? Just trying to replicate the rc example here below dynamically and flexibly.
What is the currently suggested way to do this?
Page 1 / 1
Hi!
We recently launched a new functionality called Offering metadata that I think will suit your needs. The documentation for that is in https://www.revenuecat.com/docs/offering-metadata . We also have this video from the launch that you might find useful.
Regarding the data that you’re looking for `1 MONTH`, `SAVE 38%`, you can access that information directly in the package information, there’s no need to use custom metadata for that. Not sure what’s your SDK, but in this file https://github.com/RevenueCat/purchases-ios/blob/main/Examples/MagicWeatherSwiftUI/Shared/Sources/Views/PaywallView.swift we build a paywall in Swift UI that’s similar to the one in our docs. You can build the `1 MONTH` by accessing the duration of the package and the `SAVE 38%` by calculating the most expensive package and comparing the price against the button you’re building (mostExpensive - price/mostExpensive).
You should also check out our new Paywalls feature, it’s available in iOS and Android, and in Beta for Flutter and React Native. We’ll be launching the rest of the platforms soon. Check it out here https://www.revenuecat.com/docs/paywalls, I think you’re going to like it.
I hope that helps.
Thanks @Cesar. Yes I am already using the offerings metadata for labels and to display terms and such. But since offerings are meant to group packages/products together (like 1mo, 6mo, 12mo for me all in one offering) I am not sure how it can help with individual product. Are you suggesting to add an object map like this in the metadata to cover all products? And I would copy this to all offerings and have to change it each time i moved packages inside an offering?
If so, do you not agree this would be easier to add inside each product at the product level instead of at the top level at offering where products are grouped?
Regarding `1 MONTH`, `SAVE 38%`, I am not sure where this is already available and if I have to do calculations in the client. I am using react-native-purchases (7.1.0) and I do not see where I can get this. Could you please help me there?
Is the Paywalls feature not yet available in React Native?
> But since offerings are meant to group packages/products together (like 1mo, 6mo, 12mo for me all in one offering) I am not sure how it can help with individual product.
I am not sure what you mean with “individual product”. You can treat each package as a wrapper of a product, with the advantage of being able to change the assigned product dynamically without having to change your paywall code.
For `1 MONTH`, `SAVE 38%`, etc, yes, you would have to do calculations in the client by checking the `product` inside the `PurchasesPackage` class. For `1 Month` you can use `product.subscriptionPeriod` to build it. For `SAVE 38%` you can build logic to calculate the % using the `product.price` and calculating the price per month. If you want to be able to change the “SAVE” part to let’s say something like “38% OFF” you’re going to need to add metadata to your offering.
If you build it like that, your metadata doesn’t need to be indexed by product and you could do something more simple like:
`{{ sub_duration_months }}` would be replaced in your code with “1 month”, “12 months”, etc. using the duration of the product. If you need it to be more dynamic, you could build other options like `{{ sub_duration }}` that in your code you would replace by “Monthly”, “Yearly” instead.
By the way… this is basically what we did for the Paywalls feature. We are hoping to remove the beta tag soon, if you could give that a try and report back with any issues you find, it will help us a lot to get it out of beta earlier
Understood thanks @Cesar. I will look and learn more about Paywalls but I stopped as soon as I saw beta, no documentation for react native yet, and also the min iOS version requirement. Will check if these would affect the project overall. But I felt it was a bit too soon for me. Looks cool though.
After a quick read:
Worried how customizable the paywalls are (did not see a way to list a swiper like list of benefits to upgrade to a subscription for example). Maybe paywall can tie into offerings metadata? I did see that more template will keep coming.
Is changing the paywall UI without pushing app updates against app store terms? I assume there would be someone needing to review it on the both stores and changing it post review could be an issue?
I think i saw that each paywall is tied to an offering only. They are one-to-one. Not too sure yet how it impacts a setup but I thought offerings are to be able to show different group of packages/products to a user depending on some of the user data. Currently there is one custom paywall and the offers are displayed in side that paywall. Does this mean that now it would have to be managing a paywall for each offer? would that replicate a lot of the work?
Would it be possible for the default selected package to be dynamic as well?
Worried how customizable the paywalls are (did not see a way to list a swiper like list of benefits to upgrade to a subscription for example). Maybe paywall can tie into offerings metadata? I did see that more template will keep coming.
We are constantly working on adding new templates. We can probably add a fully customizable paywall, but for now, we are adding templates as we design them. There’s currently not a template with a swiper like list of benefits, but you could use what we call a “footer” paywall view, where you can build your own paywall where you can present the list of features, and just have us display the purchase buttons. We currently don’t support Footer view in our React Native beta though . This is an example of that in iOS:
Is changing the paywall UI without pushing app updates against app store terms? I assume there would be someone needing to review it on the both stores and changing it post review could be an issue?
The changed paywall will still be compatible with the app store terms. It’s the same as like running an A/B test, where you can experiment with different wording, or colors of things.
I think i saw that each paywall is tied to an offering only. They are one-to-one. Not too sure yet how it impacts a setup but I thought offerings are to be able to show different group of packages/products to a user depending on some of the user data. Currently there is one custom paywall and the offers are displayed in side that paywall. Does this mean that now it would have to be managing a paywall for each offer? would that replicate a lot of the work?
That’s correct, there’s no way for two offerings to share the same paywall configuration. At least for now.
Would it be possible for the default selected package to be dynamic as well?
Yes, that’s an option when configuring the Paywall from the dashboard
Actually, about duplicating paywalls... it’s possible to duplicate an offering, which will carry over the paywall, so that’s a way of replicating the work on the paywall.
Thank you @Cesar . This helps and yes I can see how powerful the Paywalls are slowly getting to be.
Do you have an estimate for the beta removed and as well as when the footer option will be available for react native? Just trying to see if maybe have an option to wait for this version instead of releasing a custom paywall now. Or do you think later to move from custom paywall in react native to the RC version should be ok as well?
Although it's currently in beta, it's based on the iOS and Android versions of the feature, so it should work correctly. We're looking for feedback on the APIs (are they good / do they feel confusing, etc) and since it doesn’t have the footer view, we might make changes to the APIs in the future, so we consider it to be beta. We can’t offer an estimate on when the beta part will be removed.
If I were in your position I would probably use a full screen paywall provided by RC, then customize it further in the future when we release the footer view. Building logic for paywalls is pretty complex, so I would compromise the custom functionality with the one we provide. If you decide to go the other way, it should be fairly easy to migrate to RC custom paywall when we release the footer view.
We don’t have an estimate for the footer view, since we are focusing on adding full screen mode to all the hybrid SDKs for now. Footer views involve some complexities in the hybrid SDKs we are still analyzing.