Skip to main content
  • Community
  • Get Help
  • SDKs
  • The Paradox of Progress: Why RevenueCat’s Ever-Changing API Is a Double-Edged Sword

Hello fellow developers,

If you're like me, you've embraced RevenueCat as a silver bullet for your in-app purchase needs. The proposition is compelling: let RevenueCat handle the complex, ever-changing landscape of app monetization so you can focus on what you do best — building an amazing app. In theory, this should make our lives easier. However, a pattern has emerged that challenges this notion: the API keeps changing, and it's forcing us to constantly revisit and update our integrations.

Now, I'm all for improvements and new features. Progress is essential. But let's not lose sight of why we signed up for RevenueCat in the first place. The whole appeal of a wrapper like this is to abstract away complexity, not to introduce a new layer of maintenance.

What's the Point of a Wrapper If It Unwraps Itself?

The idea behind using a wrapper around Google Play Billing Library (or Apple's equivalent) is that we should be shielded from direct changes to these libraries. If Google or Apple changes something, RevenueCat should absorb that complexity behind the scenes, without requiring us to rewrite our implementation.

Yet, every few months, we are faced with new SDK releases that necessitate updates on our end. These aren't always simple 'drop-in-and-forget' updates; sometimes they require a fair bit of re-engineering. So I have to ask: isn't this against the philosophy of what a wrapper is supposed to be?

The Cost of Progress

I appreciate that RevenueCat is evolving. It's one of the reasons I chose it. But let's also consider the cost: Every hour spent updating RevenueCat integration is an hour not spent on improving the app or adding new features. It's counterproductive when you adopt a solution to save time and then end up investing more time to keep up with it.

A Call to Action

Developers at RevenueCat, we love what you're doing. We just ask that you be mindful of the ripple effect your changes have. Can you commit to maintaining a more stable API while still progressing and adding new features?

Fellow developers, what are your thoughts? Have you experienced similar issues? How can we collaborate to make this ecosystem better for everyone?

Looking forward to hearing your thoughts.

Best,

Antonio

Hey Antonio, 

Great write up. I 100% understand where you’re coming from. RC should really be set and forget, however we also don’t want to stagnate with poor choices we made early and continue to improve the product. It’s a balance, but I do think we could be more mindful of adding any more distraction to your plate. That’s the whole point of RC, you’re right. 

One thing I’ll suggest: you don’t really *need* to upgrade the SDK that often. We use semantic versioning, where in versions x.y.z, x represents major, oftent breaking changes, y will sometimes break small things, and z should not require any migration work. We have to support all SDK versions basically forever, so if you want to setup your dependency manager to only pickup the bug fixes, or the minors, that can improve the experience. 

Once in a a while though, like the move to Google Billing Client 5, the change are bigger and do require some investment. We can continue to improve how we do this. I appreciate you bringing it up, it’s sparked a good discussion on the balance internally.

 

Jacob

Hello Jacob,

Thank you for taking the time to respond to my concerns. I appreciate your willingness to engage in this dialogue and your openness to feedback. It's reassuring to hear that the topic has sparked internal discussions at RevenueCat, and I look forward to seeing how this evolves in the future.

Best regards,
Antonio

Reply


Terms & ConditionsCookie settings