RevenueCat’s entitlement model is built around one purchaser, one set of entitlements. That’s the right default for most apps — and the wrong shape the moment you need “one subscription, five family members” or “one company plan, a whole team.” Neither Apple nor Google’s native subscription-sharing features map cleanly onto RevenueCat’s entitlement model on their own, so the shared-access layer ends up being something you design, not something you get for free.
1. What You’re Actually Building
1
A group or household object, separate from the entitlement itself
The purchaser’s RevenueCat entitlement unlocks membership in a group your own backend manages — members’ access is derived from group membership, not a direct RevenueCat check each of them makes individually.
2
An invite and removal flow that revokes access cleanly
Someone leaving the group — voluntarily or removed by the purchaser — needs their derived access revoked immediately, independent of what RevenueCat itself is doing with the purchaser’s entitlement.
3
A single source of truth for “is the group still paid for”
Only the purchaser’s RevenueCat entitlement determines whether the group is active at all. If that lapses, every derived member’s access needs to lapse with it — this is the part that’s easy to get wrong under time pressure.
2. Where Apple and Google Diverge
🍎
Apple Family Sharing
Apple has native family-sharing support for eligible subscriptions at the platform level — but it’s opt-in per subscription and works differently from an app-managed group model. Decide explicitly whether you’re relying on it or building your own layer instead of assuming both coexist cleanly.
🤖
Google Play Family Library
Google’s equivalent has its own eligibility rules and behaves differently from Apple’s version — don’t assume feature parity across platforms without checking current store documentation for each.
🏢
App-managed groups (most B2B and health apps)
For team plans, caregiver access, or anything with an invite flow and a defined group size, most apps build this themselves on top of a single purchaser entitlement rather than relying on either store’s native sharing.
Gotcha
Store-native family sharing (where you use it) is controlled by the purchaser’s device settings, not your app — a member can lose access without your backend ever receiving an event about it directly through your own group logic. Reconcile against RevenueCat’s entitlement state on a schedule, not just on webhook events, if you’re relying on native sharing.
The entitlement fundamentals underneath all of this are the same single-user model covered in our RevenueCat integration guide — group and family plans are a layer your own backend builds on top, not a different RevenueCat primitive.
Building a family, team, or group plan on top of subscriptions?
Tell us the group size and invite model you’re picturing and we’ll scope the entitlement architecture around it.
Start the Conversation →
