@Andy I am so sorry to disturb again but do you have any hint on how to test this (because my pricingPhases is always only having 1 entry which is the subscription itself and I guess it’s because the Play Account had a subscription already and when I use a fresh Google Play account it’s also not shown maybe because there needs to be a payment method attached?).

Alternatively it would help a lot already to know how the answer would look like because mine is only looking like this:

Thank you so much, I really appreciate it and if it helps and I know that it works I am happy to post my code here for the both platforms check so that others might benefit from it as well. Testing trial is a lot harder than expected though… ;-)

Manuel

I think I finally found a working solution which is checking for trial eligibility. Since I am not sure how exactly iOS handles this, I am testing for all returned introEligibilityStatuses and a user is eligible for me if he/she is eligible for all products while excluding the products that might not have a trial which is why I am testing for INELIGIBLE and UNKNOWN and not the other way around.

For Android it seems that an entirely fresh Play Account is needed. Important to know is that you could have been subscribed quite a few times to the app with the current RevenueCat ID and only the Play Account matters to be eligible. If you care about that you would need to check for that as well if a user has been subscribed in the past.

The following code is using TypeScript and Capacitor but the approach might be similar for other tech stacks.

/**
 * Checks if the user is eligible to see a trial or intro discount. Will return true if the user is eligble but none of the current offerings have a trial or intro discount.
 */
async isEligibleForTrial(): Promise<boolean> {
    const offering = (await this.getOfferings()).current,
        productIdentifiers = [];

    if (offering.availablePackages === null) {
        return false;
    }

    for (const availablePackage of offering.availablePackages) {
        productIdentifiers.push(availablePackage.product.identifier);
    }

    if (this.platform.is('ios')) {
        // Purchases.checkTrialOrIntroductoryPriceEligibility is only available for iOS
        const introEligibilityStatuses = await Purchases.checkTrialOrIntroductoryPriceEligibility({
            productIdentifiers: productIdentifiers
        });

        // a user is only eligible if he is eligible for all products (prevents a user from using a monthly trial after an annual trial ran out)
        let isNotEligibleCount = 0;
        for (const id of productIdentifiers) {
            isNotEligibleCount +=
                introEligibilityStatuses[id].status === INTRO_ELIGIBILITY_STATUS.INTRO_ELIGIBILITY_STATUS_INELIGIBLE ||
                introEligibilityStatuses[id].status === INTRO_ELIGIBILITY_STATUS.INTRO_ELIGIBILITY_STATUS_UNKNOWN
                    ? 1
                    : 0;
        }
        return isNotEligibleCount === 0;
    } else if (this.platform.is('android')) {
        // a user on Android is eligible if one of the subscription options has a freePhase entry (it's always null if the user isn't eligible)
        for (const availablePackage of offering.availablePackages) {
            for (const subscriptionOption of availablePackage.product.subscriptionOptions) {
                if (subscriptionOption.freePhase !== null && subscriptionOption.freePhase.price.amountMicros === 0) {
                    return true;
                }
            }
        }
    }

    // for now we only check the status for iOS and Android, anything else is false by default
    return false;
}

Hey, sorry for the delay. 

For iOS: 

Eligibility works on a per-product basis, so I’d recommend not trying to have a single `isEligibleForTrial` boolean if you intend to display multiple products. Instead, you should think about it as “is eligible for a free trial of the monthly option” vs “is eligible of a free trial for the annual option”. 

There’s some extra nuance (I’ll go into it in a bit), but in general terms, you should just rely on the value that RevenueCat returns without doing any further computation. We’ll take care of de-duplication such that a user doesn’t get two free trials (one for annual and one for monthly). 

The gnarly details: 

Eligibility is actually performed on a per-subscription group basis, technically. This means that if your monthly and your annual options are in the same subscription group, and a user uses the free trial for one of them, they won’t be able to use another free trial for the other product (or for the same product). 

If products are set up to be in different subscription groups in App Store Connect, and each of them have a free trial, then yes, the user will be able to use a free trial more than once. But even if that was the case, you shouldn’t do any further computation, since ultimately it’s iOS that decides whether to grant the user a free trial or not.

So even if your logic says that the user already redeemed a free trial for another product in a different subscription group and you show a price, iOS will still automatically apply a free trial if the user is eligible.

My advice is to simply rely on the value that RevenueCat provides, and make sure to tie it to each product (so if you have a purchase button, for example, change the copy to “start free trial” for example if the eligibility for the currently-selected product was “eligible”. 

For Android: 

Your Android logic looks fine (I think you can skip the price == 0 check, but I also don’t think it’ll hurt). We do have a section dedicated to testing this on Android in our guide that might be helpful here: https://www.revenuecat.com/blog/engineering/the-ultimate-guide-to-android-subscription-testing/#free-trials

You should also be mindful of the setting in Google Play for who is eligible for a free trial from there. 

Hope this helps! 

@Andy Awesome, this helps a lot and I highly appreciate you taking the time to help. So for iOS the check right now asks for multiple product ids which is why I did the additional check afterwards because I wanted to get a single boolean result first to show a trial button directly on the products feature. When I understand you correctly it probably doesn’t even matter to add the second product id for the case when they are in one subscription group, right?

I will definitely check the subscription testing guide tomorrow, thank you very much.

If they’re in the same subscription group, and they both have free trials, then the value will be the same for the two. 

I forgot to mention, but if you happen to be on React-Native, we’re currently in beta with our own Paywalls, which take care of the intro eligibility handing automatically for you (along with other goodies like remotely making changes and A/B pricing experiments)

Here’s more info if you’re interested!

https://github.com/RevenueCat/react-native-purchases/releases/tag/7.4.0-beta.2

And if you’re on a different javascript-based SDK like Cordova / Capacitor, we’re going to work on adding support for those soon, although I don’t have an ETA just yet. 

this is confusing for testing...it would be nice if on TestFlight, the sandbox users would have a reset eligibility to verify the intro offers are available.

@Andy Great to know, so the check is for my usecase redundant but still fine for me. I feel it’s so hard to find info about details like that.

Yeah I saw the release of the Paywall feature and immediately was super hyped and wanted to use it (especially because of the AB testing and saving me a lot of time) but then I recognized that it’s not available yet for Capacitor. ;-)

@lucksp agreed! Sadly eligibility is ultimately managed by the OS, so we can’t do much on our side to make it better. 

However, for testing, here’s my advice: 

• TestFlight for intro eligibility is… well, annoying, I’d use either Sandbox or StoreKit Configuration files. 

• If you’re testing on Sandbox, you can either create multiple sandbox accounts and switch between them (that’s what I do), or use a single one, but then go into App Store Connect, find the sandbox user (Users and Accounts → Sandbox), then click Edit on the top right, select the user and click Clear Purchase History. This can take a while to take effect, though (from 1 hr to 24 hrs!). You can also access a similar option through the device in Settings → App Store → Sandbox Account. 
• If you’re testing with StoreKit Configuration files, you can actually reset eligibility very easily! You just go to Xcode → Manage transactions → delete them all. This deletes the history for the user as the app sees it… But you’ll need to also use a new appUserID in RevenueCat since sadly we don’t have a way to know that you deleted the history for the user. If you’re using anonymous IDs, a fresh install does the trick. This is the easiest way to test, but it requires a bit more setup at first. 

Hope this helps! 

@manuel-becker even though I don’t have an ETA, I’ve taken note to let you know the minute we have a beta for Capacitor 

So nice of you, thank you. I still have to get it done asap because I would love to be part of the next RC “Roast my Paywall” series but mostly because users are asking a lot for trials and not having them results in lots of 1 star ratings although the app gives away so much for free already. But that’s simply how the “app store game” works I guess ;-)

I would still love to know though because I would probably at least use it for some time to do AB testing with it. Thank you again for being so responsive here. This makes all the difference for developers like me and I highly appreciate it!

@manuel-becker happy to help! Don’t hesitate to reach out again if there’s anything else we can help with