Subscriptions dictionary loses data for same-productIdentifier products

Medium Severity

The subscriptions dictionary is keyed by productIdentifier (base), so when multiple PurchasedSK2Product entries share the same base product identifier but have different billing plans, only the last one survives. Meanwhile, the entitlements lookup on line 83 uses product.id (compound identifier), creating an inconsistency: entitlements are correctly resolved for all products, but subscription data (expiration dates, active subscriptions) is silently dropped for all but the last product with a given productIdentifier. This means products with distinct billing plans that share a base StoreKit product ID won't all appear in activeSubscriptions.

 

^{Reviewed by Cursor Bugbot for commit 2122281. Configure here.}

I don't think that this can happen in practice. StoreKit only allows you to be subscribed to one billing plan on a product at a time, so you can't be subscribed to both com.rc.product and com.rc.product:monthly at the same time, so the conflict can't occur.

But… to store kit, aren't they both actually com.rc.product?

@JZDesign yes but we are converting those to compound ids for the mapping, see the change right below.

Should we have some tests that verify what happens if we have multiple entries here, one for the "monthly" plan and one for the "upfront" with different entitlements (weird scenario... not sure if we want to support it?), and see how the offline customer info calculator would handle that?

Also, in case we don't want to support different entitlements for different "base plans", would it make sense to not include it here?

Great idea!

We do support having different entitlements across the different billing plans on a single StoreKit product. In this case, we'd want to test that com.rc.product (upFront variant) maps to one entitlement, and that com.rc.product:monthly maps to a different one.

I've updated the existing test that uses this fixture to do that here: 57352d5

Asymmetric handling of unknown billing plan types breaks offline entitlements

Medium Severity

The static compoundProductIDPlanComponent(from:) returns unknown raw values as-is (creating compound mapping keys like "product:yearly"), while the instance compoundProductIDPlanComponent returns nil for unknown types. Since BillingPlanType.from(storeKitBillingPlanType:) returns nil for unrecognized StoreKit billing plans, the device-side PurchasedSK2Product.id will be just the base productIdentifier. This means the mapping has compound keys for unknown plan types that the device-side code can never produce, causing mapping.entitlements(for: product.id) to fail for future billing plan types that the backend knows about but the SDK doesn't yet recognize.

 

^{Reviewed by Cursor Bugbot for commit 57352d5. Configure here.}

I don't think this is a case we can handle gracefully without an SDK update. If Apple introduces a new billing plan type, the raw value we get from StoreKit likely won't match the RevenueCat/backend plan identifier we use in compound product IDs. For example, the current StoreKit raw values are:

• Monthly: MONTHLY
• Up-front: BILLED_UPFRONT

So we can't safely infer the backend identifier heuristically for future billing plan types.

I also don't think this is a major concern in practice. Supporting a new billing plan type would require an SDK update anyway, and users purchasing that plan would likely be doing so through an SDK version that already knows how to map it for offline entitlements.