One Subscription, Forty People: Multiseat Is On by Default

Until now, an App Store subscription meant one buyer and one entitled person, give or take Family Sharing. As of September 2026 an organization can buy forty seats of your subscription in a single transaction — and for most subscriptions that capability is already switched on, with no code from you.

What Apple turned on, and when

On September 16, 2026, Apple’s developer news post “Get your subscriptions ready for iOS 27” stated it plainly: “Starting today, multiseat purchases are enabled by default for subscriptions in App Store Connect.”

Two launch dates follow. Volume Purchasing — organizations buying seats through Apple Business Manager and Apple School Manager — goes live October 22, 2026. Group Purchases — an ordinary customer buying several seats and inviting people — is described only as “this winter.” Apple has given no specific date, so treat any date you see elsewhere as invented.

There is a carve-out, and it is not in the news post — it lives in App Store Connect Help, under “Manage purchase options for auto-renewable subscriptions.” Subscriptions created after September 14, 2026 have multiseat enabled by default. Subscriptions created before that date are opted out if they do not use StoreKit 2 or if Family Sharing is enabled.

Read literally, that boolean leaves a specific population opted in: pre–September 14 subscriptions that use StoreKit 2 and do not have Family Sharing on. If that describes your product, you are the audience for this post. Re-read that sentence on the Help page yourself before you act on it — an OR/AND misreading inverts the advice.

One detail makes the date memorable: September 14, 2026 is the public release date of iOS 27 (and iPadOS, macOS, watchOS, tvOS and visionOS 27). It isn’t a policy deadline. It’s the OS ship line. Anything configured before iOS 27 existed got grandfathered; anything after was born into the new world.

Where the switch lives

The path in App Store Connect: Apps → your app → Monetization → Subscriptions → the specific subscription → Purchase Options → Edit. You need Account Holder, Admin, or App Manager to see it.

Two controls appear. The first asks whether a customer can purchase multiple seats. The second asks where the subscription can be purchased, with checkboxes for The App Store, Apple Business, and Apple School Manager. The Business and School channels are volume purchases only.

The asymmetry is the part worth writing down. App Store availability cannot be removed after approval. Apple Business and Apple School Manager can be removed later. So “we’ll flip it back if it goes wrong” is a real plan for two of the three channels and not a plan at all for the third.

The settings are per individual subscription, not per subscription group. A group with monthly and annual tiers is two toggles to audit, not one; five products with two tiers each is ten. The afternoon audit scales with SKU count, so count your SKUs before you promise anyone an afternoon.

Volume Purchasing and Group Purchases are not the same feature

Most of the secondary coverage collapses these into one thing. They differ in buyer, mechanism, ship date, and how much work they cost you.

Volume Purchasing (October 22): the buyer is an IT or education administrator working in Apple Business Manager or Apple School Manager. One in-app purchase, seats assigned through a device management provider. Per Apple’s WWDC26 session 391, no developer implementation is required beyond the availability configuration in App Store Connect. The purchase can happen entirely outside your app — no paywall impression, no onboarding, no signup event.

Group Purchases (winter, undated): the buyer is a normal App Store customer who buys n seats in one purchase and invites others, each joining with their own Apple Account. Here you build things: UI that explains the group value, seat-count selection, and passing the seat count into the StoreKit 2 purchase request. Apple handles invitation links, acceptance, and seat lifecycle — or you can integrate your own member system through new App Store Server API Group Management endpoints announced in session 391. Those endpoints are not in the reference documentation yet, so any custom seat-management project cannot honestly be scoped today.

One trap to avoid outright: Product.PurchaseOption.quantity(_:) is not the seat-count API. Apple’s documentation limits it to consumables and non-renewing subscriptions. Apple has published no identifier for the seat-count option yet. Announced, undocumented — expect it in an Xcode 27.x SDK before Group Purchases ships.

What breaks in one-person entitlement code

StoreKit 2 is required for both features. If you’re still on StoreKit 1, you cannot participate at all — your exposure is zero and your real project is migration.

For everyone else, here is the volume flow from session 391: the org buys, the org assigns seats through device management, the App Store generates a transaction for each assigned member, and you grant access as you would for any subscriber. Step three is where naive code fails. A transaction appears for a user who never saw your paywall.

Four assumptions stop holding. The buyer is no longer the user. One transaction no longer means one entitled person. Entitlements no longer change only at purchase, renewal, and cancellation — they change on assignment, revocation, and reassignment, asynchronously, initiated by someone else. And onboarding no longer starts at the paywall: an assigned user’s first launch is already entitled, so if your account creation hangs off the purchase callback, that user lands in an undefined state.

The entitlement side is writable today. Transaction.OwnershipType.assigned — access through an organization — is reported as back-deployed to iOS 15, so it is not gated on an iOS 27 deployment target. Confirm that with jump-to-definition in the Xcode 27 SDK before you rely on it.

func refreshEntitlements() async {
    var hasAccess = false
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result else { continue }
        guard transaction.productID == myProductID else { continue }
        // An org- or group-assigned seat is a first-class entitlement.
        switch transaction.ownershipType {
        case .purchased, .familyShared, .assigned: hasAccess = true
        default: break
        }
    }
    await MainActor.run { self.hasAccess = hasAccess }
}

// Mid-session reclamation arrives here, not at launch.
for await result in Transaction.updates {
    guard case .verified(let transaction) = result else { continue }
    if transaction.revocationDate != nil { await refreshEntitlements() }
    await transaction.finish()
}

The craft point is in the second half. A lot of subscription code checks currentEntitlements once at launch and caches a Bool. That is exactly the code that keeps serving a user whose seat an admin reclaimed an hour ago. Transaction.updates has to be live for the whole app lifetime.

One correction worth carrying: RevenueCat’s WWDC26 post names the revocation case assignmentRevoked. The StoreKit interface is reported to declare assignmentRevocation, raw value ASSIGNMENT_REVOKE. The available annotations I have are macOS-only and secondhand, so verify the spelling and the iOS availability in the SDK. Note that revocationDate != nil handles reclamation correctly without naming the type at all.

Family Sharing and the price-increase math

App Store Connect Help is explicit: “If you’ve enabled multiseat purchases for a subscription, only the group purchaser’s access will include Family Sharing. Once you turn on Family Sharing, you won’t be able to turn it off.” App Store Connect makes you confirm that acknowledgement — all other seats are individual use only.

There is a widely repeated claim that turning Family Sharing on clears the multiseat setting, so you must enable Family Sharing first and multiseat second. I could not confirm that sequencing in Apple’s Help text. It’s plausible and it’s consistent with the creation-time default rules, but it is not documented. Check it in a live session rather than trusting it.

Pricing changes shape too. Session 391 describes up to five volume price bands with quantity thresholds. Apple’s own worked example: $19.99 per seat for seats 1–20, $13.99 for 21–40, $10.99 for 41 and up, which Apple says reduces average cost by about 20% on a fifty-seat purchase. Without configuration, every seat sells at your normal price — so a forty-seat purchase at full list price is possible today with no pricing work from you at all. The band configuration surface isn’t in Help yet; it’s session 391 only.

Price increases get evaluated twice. Apple assesses the first seat price under the usual rules and the group purchaser’s total separately. For the total, consent is required only if it rises more than 50% or the purchaser is in a consent-required region — otherwise Apple notifies without asking. There is no absolute dollar floor on that test. On a forty-seat subscription, 50% of the total is a large number that can move without anyone clicking Agree.

Opting out later is not a rollback

If you disable multiseat on an already-approved subscription, new customers can’t buy multiple seats and the subscription is removed from Apple Business and Apple School Manager. But existing group subscriptions keep renewing until the group purchaser cancels, and while no new seats can be added, existing seats can still be removed.

Read that last clause carefully. Revocations keep arriving on a subscription you have “turned off.” Once one organization has bought in, you own assigned-seat and revocation handling indefinitely. Opting out stops new exposure; it does not remove existing exposure. That is the strongest argument for deciding before October 22 rather than after.

There is no authoritative recommendation either way, including from RevenueCat, which describes the complexity without picking a side. The case for opting out: Volume Purchasing goes live with no implementation work required, which means exposure begins whether or not the code path has ever been tested, and exposure is sticky once it starts. The case for staying in: Apple’s framing is that groups “can become paying subscribers today, without going through IT or procurement,” and for a read-mostly app with server-side accounts, an assigned seat may already work correctly. The audit may genuinely find zero work.

The option most coverage misses is the middle one, and Apple supports it explicitly: manage availability per channel. Keep Apple School Manager and drop Apple Business, or the reverse, or keep both organizational channels while you wait for Group Purchases to ship and its API to be documented. Session 391 lists “Apple School Manager only” as a first-class configuration.

Whatever you choose, choose it deliberately for the App Store checkbox, because that one doesn’t come back.

Verified as of September 28, 2026 — before the October 22 Volume Purchasing launch. Items flagged above as reported or secondhand were not confirmed first-hand against the Xcode 27 SDK or a live App Store Connect session.