Custom metadata on the product or package

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.

We actually just launched React Native Paywalls as a beta https://github.com/RevenueCat/react-native-purchases/releases/tag/7.4.0-beta.1

> 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:

```
{
   “offer_name”: “{{ sub_duration_months }}”
   “sub_relative_discount”: “Save N%”,
   “recommended”: “$rc_six_month”,
   “recommended_text”: “Recommended”,
   “popular_text”: { “$rc_annual”: “Most popular”, “$rc_six_month”: “Less popular” }
}
```

`{{ 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 😊

• 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 😀

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?