Skip to main content
Solved

How to handle RevCat code in TEST environment builds?

  • November 7, 2024
  • 1 reply
  • 113 views
C
Forum|alt.badge.img

Hey there, good morning!

I have this React Native app, and I have 2 separate environments for it: TEST and PROD. Naturally, both environments have separate DBs and users. My app is not live yet and I'll soon be integrating with RevenueCat, and I have a few questions on how do that, especially when I'm using the TEST env.

Question 1
Should I have separate RevenueCat projects for TEST and PROD? I believe it's best to try and avoid this, as it sounds it might get too confusing, handling multiple API keys, etc. This is an indie project, btw.

Question 2
Is it a good practice to upload TEST builds to the app store for testing? I'm assuming the best practice for sandbox testing is to always use PROD builds.

Question 3
Assuming I'll have a single RevCat PROD project and doing sandbox testing with PROD builds, that means that my TEST builds won't have any connection with RevCat/stores whatsoever. How to handle the RevCat-related code in my TEST env?

I guess I'll need to check for the TEST env and bypass the RevCat calls, implementing some dummy test behavior. Probably I won't even be able to fetch and display the offers in my TEST env.

Ex: free test user using my TEST build

  • See offers
    • I'll need to bypass await Purchases.getOfferings(); and fetch and display some dummy offers (ofc using the same response shape, as I'd get from RevCat)
  • User selects an offer and buys it
    • Then my BE will process their request, checking the env for TEST, and responding with a dummy success response, simulating that they have bought the offer.
    • Maybe I can add some flag to my user DB, saying that they are now a "premium test user"
  • Checks subscription status
    • As I won't be able to check it using RevCat with await Purchases.getCustomerInfo(); Maybe I'll need to check some user test flag in my TEST env DB. If they have the flag, they are a premium test user.

I usually don't like to write ENV-specific code, as both environments should offer same funcionality, but in this case, I believe this is the best solution for my problem.

Do you agree? Has anybody set up their projects like this?

Best answer by jeffrey_bunn

Hi @cbdeveloper! I replied to your support ticket, but wanted to share my response here as well.

There are two main ways we see our customers handle this scenario. The first is to keep things simple - create a single project and use the same RevenueCat API keys for DEV/TEST/PROD environments. Any purchase testing you do will be in the sandbox anyway, and all webhook events will contain an environment value. You can also filter Customer History and the Overview for sandbox purchases and even create a custom Customer List for sandbox purchases, so purchases from sandbox and production environments will be kept reasonably separate.

The second approach is to create separate projects for each environment. This approach certainly has more overhead, but it allows you to keep your data entirely separate. In your code, you would provide different API keys depending on environment, and you may even want to swap the bundle ID to correspond to an entirely different (unreleased) app on the App Store. One nice thing is you can add the same In-App Purchase Key for each project (that lives in the same App Store Connect account), so you don't need to replicate this step.

For an indie project, I'd generally recommend the first approach. I'm happy to further clarify, so please let me know if you have additional questions. Thanks!

View original
Did this post help you find an answer to your question?
This post has been closed for comments

jeffrey_bunn
RevenueCat Staff
Forum|alt.badge.img+6

Hi @cbdeveloper! I replied to your support ticket, but wanted to share my response here as well.

There are two main ways we see our customers handle this scenario. The first is to keep things simple - create a single project and use the same RevenueCat API keys for DEV/TEST/PROD environments. Any purchase testing you do will be in the sandbox anyway, and all webhook events will contain an environment value. You can also filter Customer History and the Overview for sandbox purchases and even create a custom Customer List for sandbox purchases, so purchases from sandbox and production environments will be kept reasonably separate.

The second approach is to create separate projects for each environment. This approach certainly has more overhead, but it allows you to keep your data entirely separate. In your code, you would provide different API keys depending on environment, and you may even want to swap the bundle ID to correspond to an entirely different (unreleased) app on the App Store. One nice thing is you can add the same In-App Purchase Key for each project (that lives in the same App Store Connect account), so you don't need to replicate this step.

For an indie project, I'd generally recommend the first approach. I'm happy to further clarify, so please let me know if you have additional questions. Thanks!

C
1 person likes this
  • C
    cbdeveloper

Most helpful members this week

Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings