Purchases.purchasePackage() doesn't return

Hello,

I am using purchases_flutter: ^5.5.0.

Testing on iOS real device + Sandbox account. The function doesn't return in my case as well.

Everything seems to work smoothly, the log goes up to "PostReceiptDataOperation: Finished". But I can't seem to get the return value of ```await Purchases.purchasePackage(package);```

I checked the config so all keys are correctly set in RevenueCat.

Do you guys have any information about that ?

Purchases.purchasePackage() call doesn’t return for me either.

I use the capacitor plugin version 7.0.0.

I tried to place a breakpoint on the API methods. All of these work fine: setLogLevel, configure, getCustomerInfo.

But purchasePackage doesn’t get executed at all. It seems the problem is somewhere in the capacitor plugin.

Hi there,

I’m using the react native package with Expo and I’ve got the same issue. It appears on Android / iPhone.

If I cancel the payment then the catch function is triggered and I can handle the situation.

But if the payment processes, I’ve got the tick from the Apple / Android payment popup. Subscription is created in revenuecat but the function never returns anything.

I’ve a “console.log(“Payment ok”); right after but it’s never executed. Neither any other code.

I’ve even tried on a new project with no other library installed, only revenuecat and the issue is here too.

@Cesar  do you have any idea?

Thanks!

Regards,
Alex

This documentation link describes how to configure and use local App Store simulator (instead of actual App Store sandbox); but I need full integration test…

Fortunately, it works with real device (when I connect iPhone to Mac, and run it via XCode on real iPhone).

And today is Nov-18-2023, still unresolved, looks like bug from Apple.

I created this issue: https://github.com/RevenueCat/purchases-flutter/issues/875 - indeed it is not just “apple” ;)

For example, Flutter library in_app_purchase: ^3.1.1 doesn’t have such issue.

We’re seeing this issue in about ~5% of our calls.

Actually, I fixed my issue. I was mistakenly calling Purchases.configure mutliple times as the call was located in a custom hook.

I moved Purchases.configure outside my component tree into the root file and instead called Purchases.logIn inside my custom hook to add the appUserId.

Works as expected now on my end. 👍

[UPDATE1]

According to some “hidden” docs from App Store, “purchases” APIs work on real physical devices; you are lucky if it works in possibly outdated not-upgraded simulator.

[UPDATE2]
“Purchases.purchasePackage(...)” is asynchronous method, and should be called in asynchronous manner. It returns “Future” instance if you call is from synchronous method. It works fine; before releasing App, I tested 40+ builds using TestFlight, I never had any issue.However, after so many tests it works super slow!!!

CustomerInfo customerInfo =
    await Purchases.purchasePackage(myProductList[index]);

It may take from 5-10 seconds to two minutes depending how lucky you are. As RC team explained, this is because App tries to download hundreds if not more purchases I did so far. I also noticed, it is super slow if my subscription expired on iPhone, and I try to resubscribe in iPad.

If you attach your device to Mac with cable, and run an app with XCode, you will see huge JSONs historical records being downloaded. Perhaps it is not real-life case when this will happen only if you replaced your iPhone with new one.

P.S. Of course RC team should optimize performance, it looks “code smell”.

P.S.S. Just in case, I added custom “Thank You” screen; after async call to “purchasePackage” starts, I show “Thank You” screen with the message saying that “your profile is being set up, usually it takes 5-10 seconds, (...), if it takes longer please log off and login again” - and I have “listener” which will close this “Thank You” screen automatically after “purchasePackage” returns. In “TestFlight”, I was forced to logout few times, it looked like “hanging”, never returns; after relogin, it worked fine, registering “premium” access. Really, it was taking minutes sometimes, and I have another forum post where RC member noted from logs that I made so many re-subscriptions during tests that’s why (still looks like code smell for me… loading collection of 1000 small JSON objects may take 1-3 seconds, but not three minutes.)

@tfletcher - I am sure my real users don’t have any issues and “purchase” in Production happens in less than a second. According to Apple, “Sandbox” is slow, and sometimes it doesn’t even work (so I periodically check https://developer.apple.com/system-status/)

In my specific case, I can give users access only after Firestore Firebase gets updated “claims” from Revenue Cat. From logs, it takes in average hundreds milliseconds instead of 10-20. So that application is listening events from Firestore, “FirebaseAuth.instance.idTokenChanges().listen(...)”, and I also trigger “FirebaseAuth.instance.currentUser!.getIdTokenResult(true);” in another “delayed future”, periodically, each 10 seconds. Even if everything works absolutely perfect and super fast, I need this routine: otherwise I will get updated “claims” within an hour implicitly.

So, sophisticated? Just because I use Firebase Custom Claims. And slow: User → App Store→ Revenue Cat → Firestore Function → (User-initiated Pull from Firestore)

What if something breaks? Fortunately, it works even when user buys from Apple on iPhone, then installs on iPad and even on Android. Because, on Android, I check Firebase Claims and do not force to buy subscription!

Otherwise, I’ll have to design custom FIrebase functions as a “webhook” for Apple, but again, what if something didn’t work and claims didn’t get updated, or, for example, everything works just perfectly but I still need to execute explicitly “getIdTokenResult(true)” from the client to force “IdTokenResult” (containing claims) instant update.

Unfortunately there are no good examples showing how to work with Firebase “claims”, I spent months to get it working.

Google had basic purchase example for server-side Node.js -based functions, https://codelabs.developers.google.com/codelabs/flutter-in-app-purchases - but unfortunately they moved away from it to separate Dart-based approach (you will need to install separate AppServer to handle purchases). So, in any case, even for an app as trivial as Google provided example, it is complicated task to ensure it is production ready.

Hi @tfletcher - thanks for sharing!

With Firebase, and Flutter, I have this loop while showing “Thank You!” screen (asking users to wait 5-10 seconds) with “logout” and “contact to support” buttons, this loop is run right after the (sync, “await”) call to “purchase”:

// this is just "compressed" snippet for illustrations only

CustomerInfo customerInfo =
    await Purchases.purchasePackage(
         myProductList[index]);

bool active =
    customerInfo.entitlements.all['premium'] !=
        null &&
        customerInfo.entitlements.all['premium']!
        .isActive;
if (active) {
    Dialogs.thankYouForSubscribing();
} else {
     ScaffoldMessenger.of(context).showSnackBar(
         SnackBar(
             content: Text("Please be patient...")));
             Dialogs.thankYouForSubscribing();
}

for (var i = 0; i < 100; i++) {
     await Future.delayed(Duration(seconds: 10),
           () async {
            // force token refresh to get updated claims
            IdTokenResult idTokenResult = await FirebaseAuth
                  .instance.currentUser!
                  .getIdTokenResult(true);
     if (/* premium subscription claim has been set up */ break;
}

Although customerInfo.entitlements.all['premium']! .isActive; is “true” after customer makes successful purchase, it is response from RevenueCat API.

I still need to wait for Firebase to update “claims”.  So that I have “loop” of 100, with 10 seconds interval.

Passing “true” .getIdTokenResult(true); enforces IdTokenResult (Firebase API) to be explicitly refreshed; otherwise it will use cached version, which, by default, refreshes once per hour.

And I also have registered listener which redirects user to “premium” content whenever “premium” claim received:

    FirebaseAuth.instance.idTokenChanges().listen(_idTokenChanges);

// _idTokenChanges will check "premium" claim:
Future<void> _idTokenChanges(User? u) async {
    ...

    if (authStateChange) await _configureRevenueCatSDK(userId: u!.uid);

    IdTokenResult idTokenResult = await u!.getIdTokenResult(
        false); // "false": no refresh needed; otherwise we are in recursive loop of triggering "_idTokenChanges"

// now, find out if it is "premium" from IdTokenResult, and redirect to "premium" screen; otherwise redirect to "paywall":
...

I released my app about 10 days ago, and I have had no complaints so far. I believe “slowness” is only in SandBox; I saw similar messages in other forums.


So, two snippets above correspond to two execution threads: 1st one will explicitly force token refresh while showing “Thank you, please be patient”; and 2nd one will listen for token updates and redirect to either Paywall, or to Premium screens. In any case, this is needed: for example, billing issues & expired subscription, etc.

P.S. If you suspect something wrong with RevenueCat SDK, try the official Google example instead and compare results: https://codelabs.developers.google.com/codelabs/flutter-in-app-purchases