Skip to main content

Today, we are launching two big improvements. Continue reading for all the nitty gritty details, but let’s start with the big advantages you have with the new features:

  • You can now share subscriptions not only between versions of the same app on different platforms (e.g., between iOS and Google Play Store), but also between different apps on the same platform.

  • We now support the Amazon Appstore for your Android apps. For more information, see our documentation on installing the SDK and configuring Amazon Appstore products.

To enable these changes, we’ve completely overhauled our model for how apps are created and set up. Logging into your RevenueCat dashboard, you will notice that the “Apps” dropdown menu has been replaced with “Projects”:

eVXggMBhCG2nXDFLiDhO8NfoCvO-2QAvkNapD4zjjaGUTnYlO3aXBPQIDLKrsHa6497uWLRDeG6VqLhvxyL_idxT-yXRWQFw915KK-wD5IZWYeeKRIthOczLzwIUWmb3L1YzyjIF

A Project is a set of Apps. Each App is specific to one platform. For example, a typical Project might contain one iOS App and one Google Play Store App. All Apps within one project share the same basic setup, including entitlements, offerings, integrations, and webhooks. 

Apps within the same Project also share the same App User ID namespace, which means that they also share subscriptions. A user logged in to the same user ID in different Apps of the same Project will have access to the same entitlements. This allows sharing of subscription status between different Apps, even on the same platform. 

All of your existing apps have been converted to Projects. You will not need to make any changes in order to keep your RevenueCat setup functional. For example, an app that was set up for both iOS and Google Play will have been converted to a Project with an iOS App and a Google Play App.

When checking out the new interface, you might notice that there are new, app-specific public API keys shown for each app. Please note that while your existing API keys are not shown in the interface anymore, they will continue to work. Newly created projects will only have app-specific public API keys.

Here are some of the most important differences you may notice in the RevenueCat interface:

  • Platform-specific configuration can now be found in the settings for the App of the platform, located under “Apps” in the left navigation (this includes StoreKit Testing, which used to have its own section in the left navigation and has been moved to the iOS App settings).

  • References to “apps” have been replaced with “projects” everywhere, including in charts and customer lists.

  • Public API keys are now app specific and can be accessed from the “API Keys” section in the left navigation.

  • Restore behavior can now be configured in the Project’s General settings, accessible from the left navigation.

  • The “integrations” section of the left navigation was cleaned up to only show configured integrations. New integrations can be configured through the “+ New” button.
    _7AB78vTz0cXraDuq1dU-4K2bfgQbIkOIztln5dRWXtTL1e-_kbqm14YdkBkL0OEjpHGQbjIpeIN8h6aA5OsH_6q4eiDfEFYv0bZPcqVG2gpQWVe_lIpMYBWz1-MWMSjrzaSuA8n

Our documentation has been updated to reflect the modified interface.

This is excellent! Is there an easy way for us to merge our auto-migrated projects into one project? I’ve already set up a workaround for sharing subscriptions between apps, but it would be much easier to make use of this new feature directly from RevenueCat. I just need to have my three existing projects become one project. 🙂


Nice changes 🥲


Hello!

 

What about the API Keys change? What will happen to live apps having the old unified API Key? For example, we use the Unity SDK and made no difference for iOS & Android (as it only was one API Key before). How and when will we be forced to make this switch? Any particular SDK version?

 

I am a bit surprised of this impacting change without previous information or time to react.

 

Thank you


Hi @Manel Simon Martínez ,

 

As per the post above:

Please note that while your existing API keys are not shown in the interface anymore, they will continue to work.

 

In other words: we will keep accepting the legacy API keys. 

If you add another app on the same platform as an already existing app to a project (eg, you add a second iOS app to your project), then you should start using the app-specific API keys – the core reason for the change in keys is the fact that you can now have two apps per platform on the same project, so (platform + project) is no longer a unique identifier.


Thanks @Jens,

I was a bit afraid as we have a lot of games using it and being forced to update them it’s quite a huge operation. Even if we update a game with new features but still having old legacy RevenueCat API Key, will they still work?

Thanks!


@Manel Simon Martínez yes, they will still work.

 


@Jens What I’m still confused about is to where to put the new keys in the Unity SDK. 

Currently, there is only one field called “RevenueCat API Key”, which holds the legacy API key. With the new system, we now have two keys: Android and iOS.

Do we need to put the correct key in the field depending on the build target, or how is this done with the new system?


@Maru : Firstly, for migrated projects and apps, you can just continue using the legacy API key.

For new projects (or if you just want to use the new API keys), yes, you will need to put the correct key in the field depending on the build target. We are currently evaluating ways to make that easier.

(Edit: Link to Unity GitHub repo with proposed change)


@Jens Yes, I know that we can just use the legacy API key, but better to get used to the new system earlier than later! :)

 

The code on GitHub looks great and this is definitely something that needs to be added. Having to manually switch (and actually remember) the key every time you build for a build target can lead to some avoidable issues. 


Reply