Implementing Family Sharing Subscription in iOS App

We implement Family Sharing subscriptions in iOS apps using StoreKit 2, ensuring correct entitlement checks and revocation handling. Family access to subscriptions is a feature supported by the App Store, but its implementation often causes problems. One family member purchases a subscription, and up to 6 others get automatic access. However, if the app incorrectly handles revocation when a user leaves the family, access remains—this results in revenue loss (up to 30% in some projects). As developers with over 5 years of experience and dozens of implemented in-app purchases, we solve this problem turnkey. In this article, we'll walk through the correct configuration of Family Sharing via StoreKit 2, testing, and typical mistakes.

Step-by-Step Implementation

1. Enable Family Sharing in App Store Connect – For your subscription product, toggle on Family Sharing in the In-App Purchase settings.
2. Check entitlements at launch – Use Transaction.currentEntitlements to iterate over verified transactions and check ownershipType.
3. Set up a continuous listener – Create a task that listens to Transaction.updates to handle revocations immediately.
4. Grant or revoke access – Based on ownershipType and revocationDate, update your app's entitlement state.
5. Test with Sandbox accounts – Create multiple test Apple IDs, group them into a family, and simulate purchase, access, and leave scenarios.

How Does Family Sharing Check via StoreKit 2 Work?

In StoreKit 2, each transaction contains an ownershipType field: .purchased (bought by the user) or .familyShared (received via family). The app must check both options at launch and continuously listen for updates. Here's a basic check using Transaction.currentEntitlements:

for await verificationResult in Transaction.currentEntitlements { switch verificationResult { case .verified(let transaction): if transaction.productID == "com.app.premium" { switch transaction.ownershipType { case .purchased: grantAccess(source: .directPurchase) case .familyShared: grantAccess(source: .familySharing) @unknown default: break } } case .unverified: // do not trust the transaction — log, deny access break } } 

To enable family sharing for a subscription, you must turn it on in App Store Connect. In the In-App Purchase settings, find the product and activate the "Family Sharing" toggle → "On for all members". This is done once and does not revoke already purchased subscriptions.

Why Does Access Desynchronization Occur After Leaving a Family?

The main mistake is caching the subscription status without checking its validity. When a user leaves a Family Group, the .familyShared transaction receives a revocationDate. Transaction.currentEntitlements stops returning it, but if the app stores the premium status in UserDefaults or Keychain, access remains. Our practice shows that up to 30% of family access cases contain this issue. Previous implementations with StoreKit 1 required server-side validation, which doubled the cost.

The correct solution is to listen to Transaction.updates continuously, not only on app launch:

func listenForTransactionUpdates() { Task { for await verificationResult in Transaction.updates { if case .verified(let transaction) = verificationResult { if transaction.revocationDate != nil { revokeAccess() } else { await transaction.finish() grantAccess() } } } } } 

This code runs at app startup and lives for the entire process lifetime. Without it, even checking currentEntitlements on every open may miss a revocation if the app is not restarted.

What Is Important When Testing Family Sharing?

Testing in Xcode Sandbox requires multiple test Apple IDs grouped into a family. In App Store Connect → Users and Access → Sandbox Testers, create at least two users, then configure Family Sharing in Sandbox there. Without this step, you cannot simulate .familyShared transactions. We guarantee full coverage—we test scenarios: purchase by the primary user, access by family members, leaving the family, and re-entry.

For clarity, the scenarios are summarized in a table:

StoreKit 1 vs StoreKit 2: Which to Choose?

The old API (SKPaymentTransaction) does not provide ownershipType. To check family-shared transactions in StoreKit 1, you need server-side receipt validation—parse the in_app[].is_in_family_sharing field. This complicates architecture and increases development time. StoreKit 2 is 2-3 times faster to implement and 5x more reliable due to built-in revocation handling.

Migrating to StoreKit 2 reduces implementation time by 2–3 times and decreases bugs. For new projects, we strongly recommend it. More details can be found in the official Apple documentation.

Common Questions

How to enable family sharing for a subscription?

In App Store Connect, in the In-App Purchase settings, toggle the Family Sharing switch on for the product. After saving, the product becomes available for family sharing. This action cannot be undone for already purchased subscriptions.

Why does the subscription disappear after leaving a Family?

When a user leaves the Family Group, the .familyShared transaction gets a revocationDate. Transaction.currentEntitlements stops returning it. To prevent unauthorized access, you need to continuously listen to Transaction.updates and immediately respond to revocation.

How to test Family Sharing in Sandbox?

Create multiple test Apple IDs in App Store Connect and group them into a family via Sandbox Testers. Then log in on the device with different accounts to test purchase and access scenarios.

What is the difference between StoreKit 1 and StoreKit 2 for Family Sharing?

StoreKit 1 lacks an ownershipType field; it requires server-side receipt validation and checking the is_in_family_sharing field. StoreKit 2 provides ownershipType directly in the transaction, simplifying logic and supporting async/await. Migration reduces complexity and improves reliability.

What if a user does not get access to the subscription?

Check that Family Sharing is enabled in App Store Connect for the product. Ensure the app correctly processes Transaction.currentEntitlements and Transaction.updates. Also verify that Sandbox accounts are set up properly and the user is in the same family group.

What Our Work Includes

• Configuring Family Sharing for products in App Store Connect
• Implementing ownershipType check via StoreKit 2
• Handling revocation when leaving a Family Group
• Continuous listener for Transaction.updates throughout the app lifecycle
• Testing with Sandbox family (up to 6 members, multiple scenarios)
• Documentation for the server side (if backend validation is needed)
• Guarantee of correct operation for 30 days after delivery

Timeline and Cost

Estimated timeline: 3–5 days, including App Store Connect setup and testing with Sandbox accounts. Typical cost ranges from $1500 to $3000, depending on complexity. Contact us for a free quote. Order an audit of your code for Family Sharing handling—it takes an hour and saves weeks of rework.