SDKs

We’re trying to display the duration of a subscription using Swift and the IOS SDK but the locale isn’t honored and the duration is always return in english, e.g. “1 Year” instead of “1 Jahr” for german with “de” locale. Does anyone have the same issue?We’re trying to access the localized duration like so:package.product.subscriptionPeriod?.durationTitle.localizedLowercaseAny tipps?

A common issue in my app has been that 1: The customer got charged2: The purchase does not reach RevenueCat3: The customer reaches out to support.4: I ask them to restore purchases and everything is synced correctly. I did read the article here: But it doesn’t contain much details on how to detect the error. I also reached out to support about this issue and got a pretty unhelpful response from support (and did not get any comment on my follow up emails).“Restoring transactions is our recommendation here. Unfortunately Apple and Google's in-app purchase process makes this a necessity. Beyond that, we don't have any general recommendations.…... Are users are complaining about not getting an entitlement after purchasing? Maybe an action item here is to show UI recommending the user to res

What is best practice for using Revenuecat Public API keys in Xcode?  Are they 'public enough' to just use in source files?

Hi, I’m new to RevenueCat and I’m in the process of refactoring a piece of code using the ‘allowSharingAppStoreAccount’ function. The documentation says:allowSharingAppStoreAccountDEPRECATEDConfigure behavior through the RevenueCat dashboard instead. I’ve looked everywhere in the dashboard, but can’t find any setting that would seem to relate to this?Also, I’m unsure exactly what this function does: is it for instance in case someone creates several accounts in the app with, say, different email addresses, but has a single App Store account? Thanks to anyone who takes the time to help!

I’m following the supplied examples and was able to list packages and buy one product. Although the process do not reach the end because of a raised error, but the error is very general, and not clear at all. Also it does not have any error code as it was supposed to according to the docs here (https://docs.revenuecat.com/docs/errors#android-errors).My Code:try { const offerings = await Purchases.getOfferings(); if (offerings.current.lifetime !== null) { const currentOffering = offerings.current.lifetime; const { purchaserInfo, productIdentifier } = await Purchases.purchasePackage(currentOffering); if (typeof purchaserInfo.entitlements.active[ENTITLEMENT_ID] !== 'undefined') { console.log("Purchase Success"); } }} catch (e) { if (!e.userCanc

Hey,I’m using react-native-purchases library and found some issue in Xcode logs. Every time initialise my app is initialised I send identifiers using:useEffect(() => { Purchases.collectDeviceIdentifiers()}, [])RevenueCat is returning error and complaining that IDFV cannot be modified. Am I doing something incorrectly? Below I’m also attaching log. Thank you 

Using RevenueCat for Unity, I am receiving json return values from RC in response to GetOfferings, RestorePurchases, etc. They usually come in the form of a PurchaserInfo object. I can’t find any documentation anywhere on the exact details of what is in this object.Specifically the date values look like this:"originalPurchaseDate":1626733276,"latestPurchaseDate":1626733275EDIT: Ohhh, these Ints are just the values shown by the XCode debugger, in C# the object contains dates in DateTime type. I was looking at the raw json data and wondering what those date numbers stood for. Still trying to find in-depth docs for the C# Type PurchaserInfo, what all is in it and how it behaves.What are these integers and how does one make them into a date? Does any documentation exist detailing the return values from RC calls?Thanks!

Background: In my flutter app it is possible for a user to sign out and another user to sign in without restarting the app.  To support this feature the app calls Purchases.init whenever a user logs in.  If the transition is non-sub to sub this works as expected IE the latter user sees their subscription. But this does not work if transition is sub to non-sub.  In this case RC fails to update to non-sub and the non-sub user appears to have a subscription until they restart the app and the sub is gone.Fix: reset all data when Purchase.init is called.

NSInvalidArgumentException *** -[__NSCFConstantString stringByAppendingString:]: nil argument This class of crashes occurs when the Purchases SDK is unable to find certain keys in NSUserDefaults, usually due to clearing NSUserDefaults. The Purchases SDK uses NSUserDefaults to store information. By default, standardUserDefaults are used, but you can configure a different instance of NSUserDefaults. To do this, set the userDefaults parameter in configure:guard let revenueCatUserDefaults = UserDefaults.init(suiteName: "com.myapp.revenuecat") else { fatalError("can't create user defaults for RevenueCat domain")}Purchases.configure(withAPIKey: <your-api-key-here>, appUserID: <the-app-user-ID>, observerMode: <observer-mode>, userDefaults: r

Logs for the Flutter SDK will appear in Xcode and Android Studio rather than in the standard Flutter logs.

Check out our new and improved walkthrough guide!  If you're still testing in sandbox, it's most likely a configuration issue that's preventing the products from being retrieved from Apple/Google. Your product identifiers are set in RevenueCat, but the actual products that your users purchase can only be retrieved directly from Apple/Google. Because this communication happens between your app and the stores, RevenueCat doesn't have any visibility into the API requests, however there are some common requirements to go through.iOS and AndroidThe product identifier set in RevenueCat matches exactly with the store You're testing on a physical device and not a simulator

If you're receiving an error message "Invalid Play Store credentials" when attempting to make a purchase on Android, it's due to the service credentials that you've added to RevenueCat being invalid: https://docs.revenuecat.com/docs/creating-play-service-credentialsBefore you go and generate new credentials, it's important to know that it can take anywhere from 24-48 hours for Google to propagate your service credential access after they're created.There are a few places to check your configuration. You have followed the configuration steps outlined in RevenueCat’s

This error could be due to a few reasons. Try the following troubleshooting steps:Make sure your device/emulator is completely updated. Try running on device. Sometimes the emulator glitches out and it must be restarted. Overall, testing on device is more reliable. Restart your device/emulator. Make sure you're logged in with a Google account. If you're running on an emulator, make sure it has Google Play installed.

Apple will randomly generate billing errors for auto-renewable subscriptions in sandbox. This is expected behavior; it's part of Apple's sandbox environment so that you can test for the billing error case.

It is highly recommended to test on a real device. This is because StoreKit is flaky in iOS simulators - it will randomly fail when fetching products, offerings, etc. Learn more on testing purchases in sandbox in our documentation.

This is the most common error from RevenueCat that can also lead to unexplained App Store rejections. Unfortunately, this error occurs when Apple's /verifyReceipt endpoint is down and unable to verify purchases. In sandbox, these errors can be fairly common since the sandbox environment is not as robust as production. In production, expect these errors less often. If your app is working in sandbox mode while testing on your own devices, this is likely an issue with the App Store. App ReviewThis issue seems to affect new apps (apps that have never been released on the App Store) during their first review more than apps that have previously been released on the App Store. Generally, the best course of action is usually to re-submit your binary or try to explain the situation to the reviewer. (Some developers have reported that they had to submit their binary over ten times before it started working as expected for the reviewer!)