Hi everyone,
I’ve been trying to wrap my head around subscription management across different devices and Apple IDs but am struggling to fully understand how it works in certain scenarios. I’m new to managing subscriptions and would appreciate any guidance or insights.
Here’s the scenario:
General Context
I have an app where users can:
- Purchase subscriptions.
- Log in to their accounts via the app or web.
- Access premium features once subscribed.
Let’s break this into a few cases to illustrate the challenges I’m facing:
Case 1: Same Apple ID, Different Devices
- Device A:
- A user (let’s call them User A) installs the app, signs up, and purchases a paid plan using Apple ID A.
- User A can log in with their credentials on Device A (or web) and access premium features without any issues.
- Device B:
- User A logs in to their account on a second device (Device B) using the same credentials.
- Here’s the problem: When I test this in a sandbox environment and try to upgrade the subscription from Device B, the paywall shows the initial purchase screen instead of an upgrade screen.
- I assume the app treats this as a new subscription attempt rather than an upgrade.
Question: Is this behavior due to testing in the sandbox environment? What will the behavior be in production? Should it allow seamless upgrades when the same Apple ID is being used across devices?Case 2: Different Apple IDs Across Devices
- Device A:
- User A installs the app, signs up, and purchases a subscription using Apple ID A. Everything works as expected.
- Device B:
- User A logs in to their account on Device B, but Apple ID B is associated with this device.
- User A can still access the premium features tied to their account (since they’ve logged in with their credentials).
- However, they should not be able to upgrade or modify the subscription because the Apple ID on Device B is different from the one used for the initial purchase.
Question: Is there a way to restrict subscription management (upgrades/downgrades) when the Apple ID does not match the one used for the original purchase?My Current Implementation
To manage subscriptions, I’ve been using RevenueCat, and I’ve implemented the following:
- On the initial subscription purchase (onboarding), I set the App User ID in RevenueCat to match the user’s unique ID in my database.
- Whenever a user logs in, I call
revenueCat.login()
to sync the app with RevenueCat’s data for that user.
Here’s what I’ve observed in practice:
- Scenario:
- User A signs up and subscribes to Plan A on Device A, where the App User ID is set to their database ID.
- User B signs up and subscribes to Plan B on Device B, with their own App User ID.
- Behavior:
- If User A logs in to Device B, the
getCustomerInfo()
API reflects the details for User A (based on the logged-in App User ID). - However, when User A tries to upgrade their subscription on Device B, the sandbox displays that Plan B is already active, likely because of Apple ID B.
- If User A logs in to Device B, the
Question:
- Is this expected behavior?
- How can I effectively manage subscription upgrades/downgrades across devices and Apple IDs?
- Is there a way to ensure only the original Apple ID/device used for the initial purchase can modify the subscription?
Desired Behavior
Here’s what I’m trying to achieve:
- Users should be able to log in and access premium features across devices, regardless of the Apple ID associated with the device.
- Subscription upgrades/downgrades should only be allowed on the same device and Apple ID used for the initial purchase.
- If a user attempts to manage subscriptions on a different Apple ID or device, they should be restricted or notified accordingly.
Key Questions
- How does RevenueCat handle these scenarios in production?
- Is there a recommended approach to restrict subscription upgrades/downgrades to the original Apple ID and device used for the purchase?
- Are there best practices for managing subscriptions across devices and Apple IDs in this type of app?
I’d appreciate any help or advice on how to handle this effectively. Thanks in advance!