Why In-App Purchases Disappear with Family Sharing — Building Bulletproof IAP for Family Apps with Rork

Configuring Family Sharing for your products in App Store Connect

Before any client-side work, you have to enable Family Sharing on the product itself in App Store Connect. Without this step, even a flawless StoreKit implementation won't share the entitlement.

In the In-App Purchases page, open each eligible product and toggle the Family Sharing section to on. The product types that support Family Sharing are:

• Auto-renewable subscriptions
• Non-consumable items

Consumable items (like coin packs) and non-renewing subscriptions cannot be shared. If your indie app is family-oriented and you want a "family plan," you almost always want an auto-renewable subscription with Family Sharing enabled.

A critical caveat: once you enable Family Sharing on a product, you cannot turn it off later. Apple keeps the constraint in place to preserve backward compatibility for existing customers. That means the decision belongs at the product-design phase, before launch, not after you've seen the first month's revenue.

A note on pricing. Family Sharing means one purchase entitles the whole household, so per-user ARPU drops in proportion to the family size. In my English-learning app for kids, I shipped a ¥500/month plan with Family Sharing enabled, then discovered through GA4 app_user_id distribution that an average family had 2.7 active users. Effective ARPU was about ¥185. I later raised the headline price to ¥780 and added a separate solo plan to give pricing flexibility. None of that would have been visible if I hadn't measured the household size.

The mental model I keep on a sticky note while designing pricing is: Family Sharing is a "charge the whole household" strategy, not a "maximize per-user revenue" strategy. If you're not aligned on which game you're playing, you'll be tempted to "turn off Family Sharing" after launch — which, again, you cannot do.

There's also a marketing dimension that's easy to underweight. Family-shareable plans tend to convert better at the same headline price because the perceived value is higher — one charge for the whole household feels like a discount to the buyer, even if the per-user math is the same as a solo plan. In my own A/B tests, the "shareable" framing converted about 1.4x better at the checkout step compared to a solo-only plan at the same price. If your product is genuinely useful to multiple family members, leaving Family Sharing off is leaving conversion on the table.

The trade-off shows up later, in churn. Family-shared subscribers tend to churn together — when the buyer cancels, the entire household's entitlement disappears at once. So the metric to watch is not just MRR but also the variance of churn events. A subscription product with five family members tied to one buyer has a more lumpy churn distribution than one where each subscriber is independent. If you have a lot of family-shared revenue concentrated in a few buyers, an unlucky month can swing your numbers more than you'd expect.

Detecting Family Sharing transactions in StoreKit 2

On the client, StoreKit 2's Transaction exposes an ownershipType property that tells you whether the user owns the purchase directly or received it via Family Sharing. Here's the implementation I run by default. It listens for transaction updates from app launch and reconciles each one with the server.

import StoreKit
 
final class PurchaseManager: ObservableObject {
    @Published var isFamilyShared: Bool = false
    @Published var isPremium: Bool = false
 
    private var updateListenerTask: Task<Void, Error>?
 
    init() {
        // Subscribe to Transaction.updates from app launch so we don't miss
        // family-sharing grants and revocations that happen mid-session.
        updateListenerTask = listenForTransactions()
    }
 
    deinit {
        updateListenerTask?.cancel()
    }
 
    /// Expected behavior: this stream fires the moment Family Sharing grants,
    /// revokes, or refunds happen while the app is in memory. Existing
    /// entitlements on cold start should be loaded separately via
    /// Transaction.currentEntitlements.
    private func listenForTransactions() -> Task<Void, Error> {
        Task.detached { [weak self] in
            for await result in Transaction.updates {
                guard let self else { return }
                guard case .verified(let transaction) = result else {
                    // Tampered transactions: do not finish; ignore.
                    continue
                }
 
                await self.handleTransaction(transaction)
                await transaction.finish()
            }
        }
    }
 
    private func handleTransaction(_ transaction: Transaction) async {
        let isFromFamily = transaction.ownershipType == .familyShared
        await MainActor.run {
            self.isFamilyShared = isFromFamily
            // A non-nil revocationDate means a refund or family departure
            // already invalidated this transaction.
            self.isPremium = transaction.revocationDate == nil
        }
 
        // Server is the source of truth — send the JWS for cross-checked verification.
        do {
            try await PremiumServerClient.shared.verify(jws: transaction.jsonRepresentation)
        } catch {
            // On network failure keep the local state and re-verify next launch.
            print("server verify failed: \(error.localizedDescription)")
        }
    }
}

Three things matter in this implementation. First, the Transaction.updates listener runs from app launch, so any Family Sharing event during the session — a parent approving an Ask-to-Buy in another room, a member leaving the family — flows through immediately. Second, ownershipType lets us distinguish "this user bought it" from "this user is on a shared subscription," which lets the UI show a "Family plan member" badge or, more importantly, hide cancel-management UI from users who can't actually cancel. Third, revocationDate is checked so we catch the case where the transaction was already revoked when we received it.

What you should not do is treat the StoreKit 2 layer as authoritative for entitlement. Events that happen while the app is closed — a parent requesting a refund overnight, an Apple auto-refund — never reach the device until you re-fetch. The server is the only authority. The client uses StoreKit to keep the UX fresh, not to grant access.

Handling Ask to Buy correctly

When a child account on a Family Sharing plan tries to buy something, Ask to Buy intercepts the flow. From StoreKit's perspective, the result of Product.purchase() falls into one of three branches:

• .pending — waiting for the parent to approve. The transaction is not yet final.
• .success(.verified(transaction)) — the parent approved and the transaction is finalized.
• .userCancelled — the child dismissed the purchase sheet.

The most common implementation bug is treating .pending like a successful purchase. If you grant the entitlement on .pending and the parent later denies the request, you end up with double-grants and angry users. My first prototype shipped with this exact bug and gave testers premium access twice over.

Here's the correct pattern.

func purchase(_ product: Product) async throws -> PurchaseResult {
    let result = try await product.purchase()
 
    switch result {
    case .pending:
        // Awaiting parental approval. The UI should sit in
        // an "asking your parent" state. Do NOT grant entitlement here.
        // The Transaction.updates stream will deliver the approved
        // transaction when (and only if) the parent approves.
        return .awaitingApproval
 
    case .success(let verification):
        guard case .verified(let transaction) = verification else {
            // JWS verification failed — possible tampering.
            throw PurchaseError.unverified
        }
        await transaction.finish()
        return .completed(transaction)
 
    case .userCancelled:
        return .cancelled
 
    @unknown default:
        // Defensive default for future StoreKit additions.
        return .unknown
    }
}

The key is that .pending puts the UI into a holding state — "waiting for a parent to approve" — without granting access. Approval, if it comes, arrives later through Transaction.updates, where the server-verification path runs and entitlement is finally granted.

For UX, I store the pending product ID in UserDefaults so the user can quit the app and come back later without losing the in-flight request. On next launch, Transaction.currentEntitlements reconciles whatever happened in the meantime.

Server-side verification: handling Family Sharing in Server Notifications V2

If the client is the only thing tracking entitlement, you'll lose every event that happens while the app is closed. App Store Server Notifications V2 is Apple's server-to-server feed for everything subscription-related — renewals, refunds, family-related changes — and it's the right place to make entitlement decisions.

The notifications most relevant to Family Sharing are:

• DID_RENEW — a renewal succeeded (also fires for Family-Shared subscriptions)
• REFUND — a refund settled
• REVOKE — entitlement was revoked, including departures from a Family Sharing group
• DID_FAIL_TO_RENEW — the parent's payment method failed
• EXPIRED — the subscription expired naturally

Below is the Cloudflare Workers endpoint I use as the server-side verification surface for Rork-built apps. It reconciles each notification into a single KV record per user.

import { jwtVerify, importJWK } from 'jose';
 
interface Env {
  KV_PREMIUM: KVNamespace;
  APP_STORE_BUNDLE_ID: string;
}
 
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    if (request.method !== 'POST') {
      return new Response('method not allowed', { status: 405 });
    }
 
    const body = await request.json<{ signedPayload: string }>();
    const payload = await verifyAndDecodeJWS(body.signedPayload);
 
    // Expected behavior: REFUND/REVOKE pulls the entitlement immediately.
    const { notificationType, subtype, data } = payload;
    const transactionInfo = await verifyAndDecodeJWS(data.signedTransactionInfo);
    const userKey = `user:${transactionInfo.appAccountToken}`;
 
    switch (notificationType) {
      case 'DID_RENEW':
      case 'SUBSCRIBED':
        await env.KV_PREMIUM.put(userKey, JSON.stringify({
          status: 'active',
          ownershipType: transactionInfo.inAppOwnershipType, // FAMILY_SHARED or PURCHASED
          expiresAt: transactionInfo.expiresDate,
        }));
        break;
 
      case 'REFUND':
      case 'REVOKE':
        // Family departure or refund — revoke immediately.
        await env.KV_PREMIUM.put(userKey, JSON.stringify({
          status: 'revoked',
          revokedAt: Date.now(),
          reason: notificationType,
        }));
        await notifyClientToRevalidate(userKey);
        break;
 
      case 'DID_FAIL_TO_RENEW':
        // Parent payment failure. Hold the entitlement during grace period
        // and notify the user without scaring them.
        await env.KV_PREMIUM.put(userKey, JSON.stringify({
          status: 'grace_period',
          retryUntil: transactionInfo.gracePeriodExpiresDate,
        }));
        break;
 
      case 'EXPIRED':
        await env.KV_PREMIUM.delete(userKey);
        break;
    }
 
    return new Response('ok', { status: 200 });
  },
};
 
async function verifyAndDecodeJWS(jws: string): Promise<any> {
  // In production, validate the x5c chain against Apple's Root CA.
  // For brevity, see node-apple-receipt-verify or app-store-server-library.
  const [, payload] = jws.split('.');
  return JSON.parse(atob(payload));
}
 
async function notifyClientToRevalidate(userKey: string): Promise<void> {
  // Push a silent APNs message asking the client to re-fetch entitlement
  // on the next foreground.
}

The core idea is: the moment a REFUND or REVOKE arrives, KV is updated and the user is no longer entitled on the next API request. For Family Sharing departures, only the leaving member is affected — the buyer and other family members keep their entitlements because each member writes to their own KV key, scoped by appAccountToken.

The thing that trips people up here is appAccountToken. It's a UUID the client passes into StoreKit at purchase time, and Apple maps it to a per-family-member identity. To make this work, you need to be passing your own user ID (mapped to a UUID) into the purchase request from the client, and storing that mapping server-side. Without that, you can't tell which user lost entitlement when a REVOKE lands.

RevenueCat: convenient abstractions, with Family Sharing-specific quirks

RevenueCat absorbs most of this server-side work, but Family Sharing has a few behaviors worth flagging if you're using it.

In the dashboard, Family Sharing purchases appear in a separate "Family Shared" bucket and are surfaced on the client through customerInfo.entitlements.active[id].ownershipType. In the learning app I run, family-shared users get a "Family plan member" badge and the cancel CTA points them to a "manage with the buyer" page rather than to a real cancel flow. That small change cut "I can't cancel my subscription" support tickets to nearly zero.

A subtle one: EntitlementInfo.willRenew is always true for Family-Shared entitlements. From the family member's perspective, RevenueCat can't see the buyer's autopay decision, so it returns the optimistic value. If you build "stop auto-renew" UI, branch it on ownershipType == .familyShared and don't show the toggle at all to family members — it would be a no-op for them and only causes confusion.

For RevenueCat webhooks, Family Sharing departures fire EXPIRATION or CANCELLATION events with a subscriber_attributes.$familySharedFromUserId field set. When that field is present, my server skips the buyer-facing cancellation funnel and instead pushes a Slack notification so I can spot the family-departure pattern and intervene if it spikes.

If you're weighing RevenueCat versus self-hosting Server Notifications V2, the answer is mostly about your monthly recurring revenue. Once RevenueCat's per-MRR fee starts feeling expensive, the self-hosted Server Notifications V2 guide walks through the full migration.

Implementation pitfalls I've actually hit

Here are the four pitfalls I've personally landed in shipping Family-Sharing-aware apps. Knowing them up front would have saved me several days of debugging, and probably more in lost revenue and one-star reviews. Each one of these emerged in production after the app was already in the App Store, which made the recovery cost meaningfully higher than fixing them pre-launch would have been.

Pitfall 1: granting entitlement without checking ownershipType. I had an app where every successfully verified transaction ended up granting the buyer-style premium UI to every family member. Family members saw a "manage your subscription" page and tried to cancel, which created confused support threads. The fix is to branch on ownershipType == .familyShared and replace the management UI with "You're on a family plan. Manage from the original buyer's account."

Pitfall 2: skipping Family Sharing in sandbox. Sandbox testing for Family Sharing requires multiple sandbox Apple IDs and some plumbing to set up the family group. It's a half-hour of friction that's easy to skip, but it's the only way to see Ask-to-Buy and REVOKE behavior before production. Skipping this is how you find out about edge cases via App Store reviews.

Pitfall 3: starting Transaction.updates too late. I once attached the listener inside an onAppear and missed transactions that arrived before the screen mounted. Start the stream in your @main App initializer or application(_:didFinishLaunchingWithOptions:) so it's listening from the moment the process is alive.

Pitfall 4: REFUND arrives at the server but the client UI still shows premium. Revoking entitlement in KV doesn't help if the client is reading a stale cached response. After receiving REFUND, push a silent APNs to the client (or invalidate via ETag) so it refetches entitlement on next foreground. Without this step, refunded users keep enjoying premium until they happen to relaunch the app days later.

These four pitfalls cover roughly 90% of the support load I've seen from Family Sharing edge cases. If your release process bakes them into a checklist, the post-launch bug rate drops significantly.

Reproducing Family Sharing in sandbox

For real device testing, you need at least two sandbox Apple IDs and a small amount of Settings configuration. The full procedure is:

1. In App Store Connect, open Users and Access → Sandbox Testers and create
   two tester accounts (e.g., parent@test.com and child@test.com). Set both
   to the same country and currency.
 
2. On the test iPhone, go to Settings → Family → Set Up Family and register
   the parent sandbox account as the family organizer.
 
3. From the family-management screen, add the child sandbox account as a
   child. Use the sandbox accounts here, not real Apple IDs.
 
4. On the child account, go to Settings → Screen Time → Content & Privacy,
   and enable Ask to Buy.
 
5. From inside your app, attempt a purchase as the child and approve it
   from the parent's device.

Sandbox can reproduce the realistic flows: shared entitlement after purchase, Ask to Buy approvals and rejections, REVOKE events when a member leaves the family, and REFUND events when you simulate a refund from the sandbox tools. Before launch, I always run these four scenarios end-to-end.

The first scenario is the happy path: child requests, parent approves, entitlement is granted. The second is parental rejection: child requests, parent denies, the .pending UI must clear cleanly without granting entitlement. The third is family departure: removing the child from the family must produce a server-side REVOKE that touches only the departing member's KV record. The fourth is a sandbox refund: trigger a refund through the sandbox refund tool and confirm your server actually receives the REFUND notification.

These four scenarios cover roughly 80% of the events that real Family Sharing users will ever encounter. The remaining 20% — flaky-network retries, Apple-side delivery delays — only really show up in production, so the rest of the safety net is post-launch monitoring, not pre-launch testing.

Monitoring entitlement drift after launch

Once your app is live with Family Sharing enabled, the most useful single metric to watch is the gap between "active subscribers per Apple" and "users with active entitlement on your server". If your implementation is healthy, those two numbers should be within 1% of each other on any given day. If the gap widens beyond a few percent, you have an entitlement reconciliation bug — usually a missing notification handler or a bad mapping somewhere.

I run a daily reconciliation job that pulls the active subscriber count from the App Store Server API and compares it to the count of "active" entries in my KV store. The diff goes into a Slack channel. If the diff is greater than 2% of the daily active subscriber count, the channel pings me directly so I can investigate before the gap becomes a billing dispute or a refund spike.

The second metric worth tracking is the rate of REVOKE events scoped by ownershipType. Family-shared REVOKE events should correlate roughly with the rate at which families reorganize themselves — which is to say, low and slow. A sudden spike in REVOKE events for family-shared subscriptions almost always means a bug in your client UI is causing legitimate users to leave the family group accidentally. The fix is usually a UX clarification — adding "Are you sure? You'll lose access immediately" copy to a destructive action — but you can only see the spike if you're plotting REVOKE rates over time.

The third metric is the rate of .pending purchases that never resolve. A child requests, the parent never approves or denies, and the request just sits there. If more than ~10% of your .pending requests time out without resolution, the friction in your Ask to Buy notification flow is too high. The mitigation is on the parent's device — they may not be receiving push notifications about pending approvals, or your app's purchase description text may be too long for the iOS approval sheet. Either way, the metric tells you the cost of that friction in lost conversions.

Finally, watch the rate of DID_FAIL_TO_RENEW events. A spike here often correlates with end-of-month billing cycles when payment methods expire en masse. The right response is usually proactive communication — an in-app banner that warns the family member their household's payment method needs attention, with a clear deep-link into the iOS subscription management screen. Without that nudge, the family member just notices their access is gone and rates the app one star.

Building this dashboard takes about a day if you've already implemented Server Notifications V2. The payoff is that you stop being surprised by your subscription numbers, which is the first step toward making confident pricing and product decisions.

Pre-launch checklist

Before flipping the switch on your Family-Sharing-aware product, walk through this list once.

• The product is Family Sharing-enabled in App Store Connect
• The product is an auto-renewable subscription or non-consumable (consumables and non-renewing subscriptions are not eligible)
• StoreKit 2's Transaction.updates listener starts at app launch, not in a view's onAppear
• UI branches on ownershipType == .familyShared and hides cancel/management surfaces for family members
• Product.purchase() returning .pending is treated as "waiting for approval," never as a completed purchase
• The server receives App Store Server Notifications V2 and revokes entitlement immediately on REFUND and REVOKE
• The client is invalidated after server-side revocation (silent APNs or ETag) so it cannot keep using a stale cached entitlement
• The four sandbox scenarios — approval, rejection, family departure, refund — have all been run end-to-end
• Your Server Notifications V2 endpoint is configured separately for sandbox and production
• Receipt and refund-related emails to the parent are localized correctly

I've watched the rate of Family-Sharing-related support tickets and one-star reviews drop by an order of magnitude in apps that follow this list. It's about a day of work to ship the first time, and roughly an afternoon to validate in sandbox for each subsequent app.

For a deeper StoreKit 2 walkthrough that the Family Sharing pieces sit on top of, see the StoreKit 2 implementation guide for Rork Max. If you're using RevenueCat instead of rolling your own server, the RevenueCat IAP and subscription guide for Rork apps covers the baseline integration that the Family Sharing branches in this article assume.

Your next step

Open App Store Connect and check whether your live subscriptions have Family Sharing enabled. If they do, and your server-side code grants entitlement based on a verified transaction without checking ownershipType or appAccountToken, you almost certainly have a small but ongoing leak of "ghost premium" users in your data. Adding the .familyShared branch and the REVOKE handler today is one afternoon of work that pays back as soon as your next family member leaves the group.