RevenueCat / purchases-capacitor

Capacitor in-app purchases and subscriptions made easy.
MIT License
155 stars 15 forks source link

(IOS) Offer Code Advice - Discussion #107

Open AdlerJS opened 1 year ago

AdlerJS commented 1 year ago

There isn't a discussion thread on this repo, so I just wanted to open something to have a running dialogue on Offer/Promo Codes with this package. I migrated my existing app from the CapGo plugin to this one and am now onto the phase of implementing promo codes for our application. On Android, it seems straightforward; set up promo codes in Google Play and have Google handle the rest natively with no code or UI changes, so to speak.

On the other hand IOS seems like a different beast. From the docs it seems like there are two ways to approach building a sign up flow UI that involves a promo code:

1.)Add UI that is along the lines of "Have a promo code" that is clickable 2.) Attach a listener for addCustomerInfoUpdateListener(...) 3.) Present the user with the redeemSheet using presentCodeRedemptionSheet() 4.) Listen for changes on CustomerInfo to see if the promo has been applied which would exist on the entitlements property

Other option:

1.) Add UI that is along the lines of "Have a promo code" that is clickable 2.) Collect the Promo code in the JS layer and dynamically build the appStore URL 3.) Attach a listener for Browser.addListener('browserFinished', () =>) 4.) Redirect the user to the appStore link using Browser.open 5.) On browser finish event call syncPurchase then look at the customerInfo to see if an active entitlement exists

Both of these seem like okay options, but I wanted to get opinions on best practices, as it seems that presentCodeRedemptionSheet is unstable at the Apple level. Another issue I am running into is that promo codes are not testable in a sandbox environment, so I would be looking for the best options to not only build the UI but test it to ensure it's stable before releasing to users.

aboedo commented 1 year ago

Hi @danbunkr! 👋

The presentCodeRedemptionSheet API is pretty unreliable, we've had a lot of issues with it in the past and we just recommend staying away from it. Sometimes it just doesn't open, sometimes it opens and its blank, and there's variety in terms of OSes (it even crashes in macOS Catalyst IIRC?).

So your understanding here is spot on.

We recommend going with the "Other option" you described. I imagine you already found the docs since you describe the approach very accurately, but just in case: https://www.revenuecat.com/docs/ios-subscription-offers#2-redeeming-an-offer-code

AdlerJS commented 1 year ago

Hey @aboedo. Appreciate the response. I did find the docs and figured that option 2 would be the best way to approach this feature. The last remaining issue is that it appears that promo codes are not able to be tested in sandbox environments on IOS. This seems like a pretty major hurdle as you would have to build an entire UI / signup flow and then send the app to production and just hope you got everything right? Is there a recommended approach on how to test the promo / offers codes using option 2 in a develop environment? Or even an approach where we could test in production without having external users able to access that feature in the app?

aboedo commented 1 year ago

@danbunkr I have good news on that front!

For Option 1: Apple recently shipped an update in Xcode Beta (well, at this point you can use the RC build), that allows you to set up Offer Codes for testing, and it should work correctly with RC. They have detailed instructions here: https://developer.apple.com/documentation/storekit/appstore/supporting_subscription_offer_codes_in_your_app#4281583

And here are the instructions to set up a StoreKit Configuration file with RevenueCat: https://www.revenuecat.com/docs/apple-app-store#step-1-add-a-storekit-configuration-file

For Option 2: If offer codes work on Option 1, then they should work for Option 2, but obviously that's not a great answer in terms of testing. Truth is that testing Offer Codes has been nearly impossible for years and it's been our biggest complaint about the feature, even more so that the API's unreliable behavior.

One thought is that you could leverage Offerings Metadata as a way to set up a feature flag that you enable for yourself to test with in production. We're working on updating the docs for Capacitor for it, but it's available through offering.metadata.

Hope this helps!

AdlerJS commented 1 year ago

@aboedo - That does help a lot thanks! Just to clarify you are saying I would need to be on Xcode 15 Beta (RC version) to test the offer codes locally?

aboedo commented 1 year ago

@danbunkr oh gosh I missed your reply! Yes, that's what I meant