Sticky

RevenueCat CEO checking in


Userlevel 2
Badge +1

Hi! I’m Jacob, recovering iOS engineer and CEO of RevenueCat. 

 

It’s still a bit mind boggling how many folks are using our little SDK these days, and I’m excited that we have an open community to chat about it.

 

I’d love to hear your product and company feedback. I don’t get to spend nearly enough time with developers using our product day-to-day and would love to hear what direction you think we should take the SDK, the dashboard, and ultimately the company. We are here to help you make more money with your apps, so tell us what you need!

 

P.S. I’m thinking about making an app. Can you still make apps in Objective-C?


26 replies

Userlevel 2

I was actually thinking of emailing you yesterday, so I’m glad you posted this.

RevenueCat is very close to being one of those unicorn apps that just magically removes an entire subset of problems for businesses. I’m an engineer and CEO of a few software businesses and have done technology consulting for hundreds of others, so there are some things I’d strongly urge you to consider in order to round-out what RevenueCat is doing to consume the rest of the “problem.”

The problem, of course, is that in-app subscription management is a gigantically stupid pain in the ass, precisely multiplied by the number of platforms you need to support. We all want subscription management to be as close to “press a button and it’s all done” as possible and RevenueCat is getting rather close to that.

  1. There needs to be a subscription expiration notification.

This is a small hole but a big oversight. I understand the RevenueCat webhook system is designed to mimic the app stores’ webhooks, but the app store webhook logic is horrible. Generally speaking, businesses want to know when to give the goodies, and when to take the goodies away. Just tell us, please. Notify on entitlement activation and deactivation — or some equivalent.

Right now you have to build your own polling system to figure out when to expire entitlements. This is super silly. RevenueCat is already 98% of the way to removing this chunk of work.

  1. Design a best-practice backend and really highlight it.

Almost every business needs the identical backend purchase logic, and then they add their own business logic on top of it. There are many SDK examples and backend examples spread around the docs and GitHub, but there should be a simple best-practice systems tutorial as part of the onboarding process.

It takes awhile to figure out the best practice is to essentially build a backend webhook processor, configure it in RevenueCat then build a sync function that triggers on any IAP or those backend webhooks. That’s a really great systems design but it’s not fully spelled out anywhere. It should be!

  1. Consider adding a web SDK (and secondarily, web support to the Flutter SDK.)

Web SDK is kind of a no brainer. It’s also common practice to build a Flutter mobile app using RevenueCat and then adding a web version later. If you do this, you’re in for some hurt, because the Flutter SDK doesn’t work when you do that. As a result, you end up with 2 implementations: use the RevenueCat SDK in your mobile apps, and then write your own RevenueCat web SDK for your web app. This is a bit silly and it seems like adding a web SDK and then expanding the Flutter SDK to use the web implementation you wrote could be a good strategy on a number of levels.

  1. Keep moving towards simple and intuitive! The recent SDK changes to logIn() and logOut() are perfect examples.

This was a small but excellent move. Keep it up!

I hope this is at least somewhat helpful towards the kind of feedback you’re looking for.

Thanks Jacob for all of your work!

 

Userlevel 3
Badge +3
  1. There needs to be a subscription expiration notification.

You’ll be pleased to hear (I hope, at least) that we’re working on this right now!

Badge

Hi Jacob. If in the next version of your SDK you could reduce my churn from 16% to 10% that would be great. Should be easy enough.

Jacob,

 

Have been using the product in production for a little over a month now and have been generally pleased. One key feature missing for me is the ability to get a list of users who are on trial and their renewal dates. I want to proactively communicate with users ending a trial and coming up on renewal but I have no way of getting that info.

Badge +1

Jacob,

 

Have been using the product in production for a little over a month now and have been generally pleased. One key feature missing for me is the ability to get a list of users who are on trial and their renewal dates. I want to proactively communicate with users ending a trial and coming up on renewal but I have no way of getting that info.

OMG yes. What I would do to have an easy way to just see an ordered list of users sorted by trial expiring date so I know how many people are due to convert from a trial and when

Userlevel 4
Badge +8

@Dani Waxman @Ilya Usorov 

Have you checked out Customer Lists? https://docs.revenuecat.com/docs/customer-lists

 

The default sort order in the dashboard will be by recently active, BUT you can export the .csv and slice-dice it however you’d like in Excel or Google Sheets.

 

You could make a list of customers that have a trial expiring soon and have auto-renew turned off… Hopefully you can engage with them before the subscription cancels and either win them back or get product feedback. 

 

What I would do to have an easy way to just see an ordered list of users sorted by trial expiring date so I know how many people are due to convert from a trial and when

The Trial Conversion chart (in the new Charts v2) can answer part of this, how many are due to convert, but you don’t get the exact date when they’re set to convert. Will pass this feedback on to @Jens 

Badge +1

@Dani Waxman @Ilya Usorov 

Have you checked out Customer Lists? https://docs.revenuecat.com/docs/customer-lists

 

The default sort order in the dashboard will be by recently active, BUT you can export the .csv and slice-dice it however you’d like in Excel or Google Sheets.

 

You could make a list of customers that have a trial expiring soon and have auto-renew turned off… Hopefully you can engage with them before the subscription cancels and either win them back or get product feedback. 

Yes, I’ve played with Customer Lists in all the ways I could figure out.

I’m actually going to get on a call with David from your team in a bit and I can show him the custom view I ended up building in my CMS to get what I was looking for.

 

@Dani Waxman @Ilya Usorov 

Have you checked out Customer Lists? https://docs.revenuecat.com/docs/customer-lists

 

The default sort order in the dashboard will be by recently active, BUT you can export the .csv and slice-dice it however you’d like in Excel or Google Sheets.

 

You could make a list of customers that have a trial expiring soon and have auto-renew turned off… Hopefully you can engage with them before the subscription cancels and either win them back or get product feedback. 

 

Thanks- I also have played with the customer lists - how would you filter by “expiring soon”?  I am also not only looking for people who are not renewing- I want to engage with those renewing soon (ie.. trial ending soon and need to decide if they are renewing or not). 

Having a next renewal date  or Expiration column like on the recent transactions list -  and making it sortable in the customer list I believe would solve the issue. 

Would love to hear how you manages to export to sheets and work with this - is it automated? Perhaps a Zapier integration can provide the info. 

Userlevel 1
Badge +2

I disagree with some of the replies when people suggest expanded directions for Revenuecat… 

I think Revenuecat’s core competency and primary value is a multi-platform subscription management solution.  It is not a CRM, not an Auth/Identity provider, not a reporting solution.  We in Brightmind use RC integrated with Firebase/Auth and Segment.io which in turn supports integrations with a long list of solutions such as Amplitude.io (reporting) and customer.io(email/CRM sort of) etc.  This gives us lots of flexibility to choose best-of-breed solutions.  We have been very happy with this approach.

I think Revenuecat should stay focused on all issues around subscription management. You do it very well and you save us a HUGE headache!  Please keep your focus and stay in sync with Apple and Google!

Userlevel 2
Badge +1

I disagree with some of the replies when people suggest expanded directions for Revenuecat… 

I think Revenuecat’s core competency and primary value is a multi-platform subscription management solution.  It is not a CRM, not an Auth/Identity provider, not a reporting solution.  We in Brightmind use RC integrated with Firebase/Auth and Segment.io which in turn supports integrations with a long list of solutions such as Amplitude.io (reporting) and customer.io(email/CRM sort of) etc.  This gives us lots of flexibility to choose best-of-breed solutions.  We have been very happy with this approach.

I think Revenuecat should stay focused on all issues around subscription management. You do it very well and you save us a HUGE headache!  Please keep your focus and stay in sync with Apple and Google!

Agreed. We have sort of realized this in the last few months ourselves. We fell behind on a few parity features for Google and realized that wasn’t the level we wanted to provide. I think this happened partly because we (mostly me) were thinking too much about building our new feature roadmap, and not leaving enough bandwidth for covering the core as Apple and Google keep changing things. Really, RevenueCat “core” should always be our #1 priority. 

As we grow as a company, there will probably be opportunities to serve other needs as well, but I think they all have to tie back to the thing we do really well, multi-platform subscription tracking.

I strongly agree with @James  post, I was surprised to see RevenueCat 98% of the way there and then leave out expiration notifications (instead I had to build my own system to set up a future cron job basically to remove entitlements upon the expiration_at_ms time).

One key pain point for me is the dev experience of how to sync users. Every once and a while a user ends up in some weird state and it’s frustrating because I expected RevenueCat to abstract away all of these weird edge cases. See my HN comment on the specifics: https://news.ycombinator.com/item?id=27290318 (I just realized you actually replied to it) I’ve been told that instead of handling individual webhook reasons, I should just sync with the API on any webhook call - but there are not good docs on how to handle the response to get the following info that every app needs to know:

  • What the user is currently paying for
  • What the user is currently entitled to

Which are often the same, but it’s very important to know the difference when the user is currently in a downgrade/upgrade transition. If a user cancels they are entitled to their plan for the remainder of the period, but the app should say “you are not subscribed to a plan” on the billing page for example (so that the buttons to re-subscribe are available). I really just want a good way to have that info, but if I use the API to sync users then I get an array of entitlements and subscriptions and need my own logic to find what is “active” (which may seem simple, maybe the latest subscription as the “paying for” item and the highest tier as the current entitlement, but I’m not sure what kind of edge cases that logic has, I just want the API to tell me what to display to the user and what to give access to)

Userlevel 2
Badge +1

I strongly agree with @James  post, I was surprised to see RevenueCat 98% of the way there and then leave out expiration notifications (instead I had to build my own system to set up a future cron job basically to remove entitlements upon the expiration_at_ms time).

One key pain point for me is the dev experience of how to sync users. Every once and a while a user ends up in some weird state and it’s frustrating because I expected RevenueCat to abstract away all of these weird edge cases. See my HN comment on the specifics: https://news.ycombinator.com/item?id=27290318 (I just realized you actually replied to it) I’ve been told that instead of handling individual webhook reasons, I should just sync with the API on any webhook call - but there are not good docs on how to handle the response to get the following info that every app needs to know:

  • What the user is currently paying for
  • What the user is currently entitled to

Which are often the same, but it’s very important to know the difference when the user is currently in a downgrade/upgrade transition. If a user cancels they are entitled to their plan for the remainder of the period, but the app should say “you are not subscribed to a plan” on the billing page for example (so that the buttons to re-subscribe are available). I really just want a good way to have that info, but if I use the API to sync users then I get an array of entitlements and subscriptions and need my own logic to find what is “active” (which may seem simple, maybe the latest subscription as the “paying for” item and the highest tier as the current entitlement, but I’m not sure what kind of edge cases that logic has, I just want the API to tell me what to display to the user and what to give access to)

 

Yeah, the /subscribers endpoint was initially (and still is) designed to service our SDKs and wasn’t really intended for public consumption. We started sending it to folks who needed it since it was likely to be stable given the way SDKs and APIs interact, but it wasn’t really designed for that use case. 

“Developer API v2” is on our roadmap, though it’s pretty fuzzy at the moment, but we’d like to do a rethink of the REST API to follow all best practices of API design and to be really friendly to build on. What we have currently isn’t quite there yet, your reasons above are definitely part of that. 

Badge +1

@Jacob Eiting +1 to the above point from Heath as well.

I actually asked the question (to Dylan) “what’s the reason for the difference in the shape of the data returned from the mobile SDK “getPurchaserInfo” method compared to the REST API "Get or Create Subscriber” endpoint?” right when I was starting to implement RC, and got the answer that the REST API had to be simple so that it could be backwards compatible forever, while in the SDK you could mess around with data shapes.

Then I wrote back that anyway “I ended up standardizing on the REST API data model and using that as a source of truth (i.e. after any event refreshing from the "Get or Create Subscriber” endpoint), with the purchaserInfo model stored as a secondary data source which may be out of sync with the REST API endpoint at times if the user hasn’t engaged with the app recently. This did involve me having to manually calculate which subscriptions are active, but it was simple enough.

This seemed like kind of a janky approach, but it was the best way I could figure out how to keep things in sync. Hope this could help anyone else thinking about the synchronization issue.

Hey @Jacob Eiting, discovered RC thanks to the podcast recently and my first app using it is already live and it has been so easy!

I was just wondering if you could share more info Huawei IAP roadmap, I've seen it discussed in a few places since last year, but would be great to have more clarity.

Also I would really appreciate if you could provide some clarity around RC working in China, I've seen posts from a year ago that say that is a bit hit or miss. I want to use RC for my next project but need to be sure that is reliable in the chinese market. Does RC have any cloud infrastructure over there?

Thanks for checking in!

Userlevel 2
Badge +1

I was just wondering if you could share more info Huawei IAP roadmap, I've seen it discussed in a few places since last year, but would be great to have more clarity.

It’s on the roadmap, and probably the most requested new platform. We’re currently working on a UI/data model update that will let us add new stores more easily. The SDK team is working a lot on StoreKit 2 support, we’re having to convert our SDK to swift for that. After that though we’ll look to new platforms. Sorry, still too far out to give a firm date.

Also I would really appreciate if you could provide some clarity around RC working in China, I've seen posts from a year ago that say that is a bit hit or miss. I want to use RC for my next project but need to be sure that is reliable in the chinese market. Does RC have any cloud infrastructure over there?

This is entirely up to the great firewall and whether or not they allow us through. I know they do block some SDKs, I believe Mixpanel is one. Suffice to say it’s in our long term interest to ensure the RC SDK work seamlessly on the global internet, but we’re not in a position to actively ensure that at the moment. We do have workarounds however: using SDK traffic proxies should our main domain become blocked. 

I was just wondering if you could share more info Huawei IAP roadmap, I've seen it discussed in a few places since last year, but would be great to have more clarity.

 

Also waiting for this option:)

Badge

I’m a new user of RevenueCat,

like many others I looked for an In App Purchase validation solution and found you.

I’m part of a team that own and manage 50+ apps, and purchase between 5-10 more every month.

In App Purchases are a major part of our business.

 

At first glance RevenueCat was what we needed and even more,

however after i started working with the systems i found some features that have room for improvement.

 

The First is the procedure of products configuration on the dashboard.

 

Currently to configure the product you have to follow these steps:

  1. Set up the product on the store(Apple, google, stripe).
  2. On the Dashboard insert each product for each platform separately
  3. Move to the Entitlements
  4. Create new Entitlement
  5. Attach 1 product from a specific platform to the Entitlement(repeat if needed)
  6. (Repeat 4-5 until finished)
  7. Move to the Offerings screen
  8. Create an Offering
  9. Create 1 Package inside the offering
  10. Attach 1 product from a specific platform(repeat if needed)
  11. (repeat 8-10 until finished)

 

this procedure takes a lot of time and is complicated and is over complicated,

however it can be much simpler and faster.

 

This will be achieved by these changes:

  1. Have a new screen to configure Packages
  2. When setting up the package the user inserts all 3 products(1 for each platform) and can chose the entitlement(if it’s already created)
  3. When setting a new entitlement have the option to attach packages to it(if already created)
  4. When attaching packages to entitlement have each package with a checkbox so multiple options can be chosen at a single time
  5. when setting a new offering have the option to attach packages to it(if already created)
  6. When attaching packages to offerings have each package with a checkbox so multiple options can be chosen at a single time
  7. Discard the products screen

 

This way there are 3 levels to configure and less time is needed for it.

 

 

The Second is the Collaborators.

 

Currently there are 3 permissions and they are per app:
1. Admin

  1. Customer Support
  2. Read Only

 

these permissions are fine for a single developer but don’t fit a team need.

they can be divided in a way the works for both single developers and bigger teams and be controlled form a system wide perspective with the ability to assign specific apps to different team members all from one place.

 

How?

  1. Move the Collaborators screen to the Account section.
  2. in the screen have the ability to assign already created apps to different Collaborators
  3. Have the following permissions levels:

 

A. Admin

Full system wide access including billing

For Management members and their Personal assistants.

 

B. Manager
one who can invite other users and can have system wide access to all feature except billing.
We have technical members on our team who can take load off the developers, and product managers who run the teams of each app, they fit this permission perfectly.


C. Developer

one that can set up an app, get keys and configure products

We have several developers who work with us, they don’t work on every app and some of them are only experts of a specific development language.

this way they have the access to grab all the information they need in order to focus on the development itself.

 

D. Analyst

one who only has access to the different chart related to the In-App Purchases performance

 

 

And last but not least,

the option to display a specific package on the app.

 

while using permissions to display products on the app is a very dynamic way,

it lacks control over the location each product is presented and insight on the way the user interacts with the app.

for us specifically it disallow the use of our highly converting sales screen.

 

 

From what i saw and read about RevenueCat you guys listen to your customers and i’m sure you’ll evolve to add these sometime in the future.

I do hope that it will be the near future because unfortunately right now our team has to look for another solution or a platform.

 

If there are solutions to these problems in the system please let me know as i havn’t found them yet.

 

also i’m available for any RevenueCat team member if you have any further questions for me :)

Badge

A community forum is great, but the problem is questions almost always go unanswered, which is terrible support. Answer community questions. There’s nothing more frustrating than blocking technical support questions going unanswered. 

Userlevel 2
Badge +1

A community forum is great, but the problem is questions almost always go unanswered, which is terrible support. Answer community questions. There’s nothing more frustrating than blocking technical support questions going unanswered. 

Absolutely. (Let me know if you’re having this experience now, but I think you’re speaking generally.)

We’re incorporating open community questions into our normal support rotation to help make sure folks aren’t blocked. Our goals with the community are to create more bidirectional communication, allow solutions to be referenced across developers (right now when we solve a ticket, it’s hard to use that experience to pre-empt another ticket), and hopefully create a better developer experience than we had before. 

We definitely screwed this up with our old Spectrum community, but we learned a lot from that experience and have engineered this version better. However, if we start failing on that, please, call me out.

Badge

A community forum is great, but the problem is questions almost always go unanswered, which is terrible support. Answer community questions. There’s nothing more frustrating than blocking technical support questions going unanswered. 

Absolutely. (Let me know if you’re having this experience now, but I think you’re speaking generally.)

 

Hi Jacob,

Hate being the annoying guy at this party but it’s kinda is happening for me…

I asked a question and although one team member did respond fast initially when i sent a replay he did not respond back.

Also the matter of choosing the right section was unclear to me and maybe that’s what’s causing my answer to show less and stay unanswered for almost a week.

Userlevel 2
Badge +1

Hate being the annoying guy at this party but it’s kinda is happening for me…

 

Ha, thanks for bringing it up.

 

Looks like me and Ryan both answered the question deeper. We’re still figuring this thing out. 

 

Also the matter of choosing the right section was unclear to me and maybe that’s what’s causing my answer to show less and stay unanswered for almost a week.

 

That’s good feedback. I think that was the right place to ask it as it’s kind of a question about how to achieve something app specific with our SDK, and not an issue. But I’m not sure. We’ll likely iterate and refine things as we learn more.

For me it would be first class support for Xamarin Forms and MAUI.

Badge

Hei there.

Congrats on the new community, looking forward to find all the answers I need and maybe even help put others.

I have one thing that I think could be better in the REST API: Either split the “Get or Create Subscriber” endpoint into a get subscriber and a create subscriber endpoint or add an endpoint to check if a subscriber exists. 

Currently I have to call the “Get or Create Subscriber” endpoint with a userId I want to validate and if it doesn’t exist I have to delete it afterwards, because a new subscriber was created…

Or is there a different way of knowing if a given userId exists?

Userlevel 3
Badge +3
  1. There needs to be a subscription expiration notification.

This is a small hole but a big oversight. I understand the RevenueCat webhook system is designed to mimic the app stores’ webhooks, but the app store webhook logic is horrible. Generally speaking, businesses want to know when to give the goodies, and when to take the goodies away. Just tell us, please. Notify on entitlement activation and deactivation — or some equivalent.

Right now you have to build your own polling system to figure out when to expire entitlements. This is super silly. RevenueCat is already 98% of the way to removing this chunk of work.

@James: We just shipped support for this!

 

We have been using RevenueCat for two years and are very happy. In fact, we are so happy with using RevenueCat that we are stalling on entering markets where we cannot use it. Amazon App Store and Huawei App Gallery support is what would move the needle the most for us. Being able to enter those markets and synchronize purchases would be amazing! (Amazon App Store coming to Windows 11 is also an important factor)

Reply