> Multiseat Subscriptions Are On by Default: What to Check in App Store Connect

Last week Apple changed a default on almost every auto-renewable subscription in App Store Connect. Multiseat purchasing, which lets one buyer pay for several people's access, is now turned on unless you turn it off. Nothing changes for your customers yet, but the first way to buy multiple seats goes live on October 22, so now is a good time to decide whether you want it.

The announcement came in Apple's Get your subscriptions ready for iOS 27 post, and today's App Store Connect API 4.5 release added the attributes to manage it from code. Here's what you need to know before the switch matters.

What Multiseat Means

Apple is adding two ways for groups to pay for your subscription. The WWDC26 session Offer subscriptions to groups and organizations walks through both.

Volume Purchasing happens in Apple Business and Apple School Manager. A company or school buys seats of your subscription in bulk, then assigns them to people with the same device management tools it already uses to hand out apps. You don't build anything for this path, since Apple's portals show your subscription and handle the purchase. It launches on October 22, 2026.

Group Purchases happen inside your app. A customer, whom Apple calls the group purchaser, buys several seats and shares an invite link, and anyone who accepts gets a seat. Think of a small team splitting a design tool or a running club sharing a training app. Apple's news post says Group Purchases arrive this winter.

In both cases Apple handles the seat bookkeeping by default: generating invitations, tracking who accepted, and dealing with cancellations. According to the session, once a seat is assigned the App Store creates a transaction for that member, and you unlock access the same way you would for any other subscriber. Every seat sells at your normal price unless you set up volume pricing, which Apple describes as up to five price bands with cheaper seats for larger purchases.

Which Subscriptions Got Opted In

The short version is most of them. Apple's help article on managing purchase options says multiseat is on by default for all auto-renewable subscriptions, with one carve-out for older ones. If a subscription was created before September 14, 2026 and either doesn't use StoreKit 2 or has Family Sharing turned on, it starts out opted out.

The StoreKit 2 condition isn't arbitrary. The WWDC session is explicit that selling to groups and organizations requires StoreKit 2, so if your app still uses the original In-App Purchase API, multiseat isn't available to you until you migrate. My StoreKit 2 guide covers that move.

Family Sharing interacts with multiseat in a specific way. If both are on, only the group purchaser's own access can be shared with their family, and every other seat is for individual use. Turning on Family Sharing also flips the subscription's multiseat setting off, so if you want both, turn on Family Sharing first and then switch multiseat back on. Think that order through before you start, because once Family Sharing is on, App Store Connect won't let you turn it off again.

Custom apps are the exception in the other direction. Subscriptions in custom apps are automatically available in Apple Business and Apple School Manager, and you can't opt them out.

Changing the Setting in App Store Connect

You'll need the Account Holder, Admin, or App Manager role. The setting lives with the subscription's availability:

1. In Apps, open your app.
2. In the sidebar, under Monetization, click Subscriptions, then click the subscription.
3. In the Purchase Options section, click Edit.
4. Answer "Can a customer purchase multiple seats for this subscription?" with Yes or No.
5. Under "Where can a customer purchase this subscription?", choose any of the App Store, Apple Business, and Apple School Manager.
6. Click Save.

The store choices are more flexible than an on/off switch. The App Store covers both individual and group purchases, while Apple Business and Apple School Manager only sell multiple seats, so those two require multiseat to be on. That means a new subscription could, for example, be offered only through Apple School Manager.

Some of these changes are hard to undo once customers depend on them, so read Apple's notes before saving. After a subscription has been approved, you can't remove App Store availability. Removing Apple Business or Apple School Manager from an approved subscription takes the Account Holder, and the subscribers who bought through those channels won't renew automatically. Apple says they're canceled at the end of their next renewal.

Turning multiseat off is gentler on existing customers. New buyers can only purchase a single seat, and the subscription disappears from Apple Business and Apple School Manager, but existing group subscriptions keep renewing until the group purchaser cancels. They can't add seats, though the group purchaser can still remove them.

Managing It with the App Store Connect API

App Store Connect API 4.5 adds two attributes to the subscription resource, which is handy if you manage many subscriptions or keep your configuration in scripts. multiSeatStatus is either ENABLED or DISABLED, and marketSettings is an array of APP_STORE, APPLE_BUSINESS, and APPLE_SCHOOL.

You update both with the existing Modify an auto-renewable subscription endpoint, PATCH /v1/subscriptions/{id}. Here's a payload that keeps multiseat on but limits it to the App Store and Apple School Manager:

{
  "data": {
    "type": "subscriptions",
    "id": "6502113348",
    "attributes": {
      "multiSeatStatus": "ENABLED",
      "marketSettings": ["APP_STORE", "APPLE_SCHOOL"]
    }
  }
}

To opt out entirely, send "multiSeatStatus": "DISABLED" on its own. marketSettings only matters while multiseat is enabled, so there's no need to clear it. Then read the subscription back with GET /v1/subscriptions/{id} to confirm both values. Apple's guide, Configuring multi-seat subscriptions for organizations, has the full details. The same roles apply as in the web UI, and API keys with the Marketing role can read these attributes but not change them.

What to Check in Your App

The biggest risk is in your entitlement code. StoreKit 2 already has an ownership type for this, Transaction.OwnershipType.assigned, which Apple describes as access through an organization. It's back-deployed to iOS 15, so it's there on every version that runs StoreKit 2. Code like this would lock those people out:

import StoreKit

func isSubscriberStrict() async -> Bool {
    for await result in Transaction.currentEntitlements {
        if case .verified(let transaction) = result,
           transaction.ownershipType == .purchased {
            return true
        }
    }
    return false
}

A safer approach grants access for any verified, unrevoked entitlement and keeps the ownership type around for decisions that really depend on who paid:

import StoreKit

struct SubscriptionAccess {
    let productID: String
    let ownership: Transaction.OwnershipType
}

func currentSubscriptionAccess() async -> SubscriptionAccess? {
    for await result in Transaction.currentEntitlements {
        guard case .verified(let transaction) = result,
              transaction.productType == .autoRenewable,
              transaction.revocationDate == nil else { continue }

        return SubscriptionAccess(
            productID: transaction.productID,
            ownership: transaction.ownershipType
        )
    }
    return nil
}

func shouldShowBillingOptions(for access: SubscriptionAccess) -> Bool {
    access.ownership == .purchased
}

Hiding upgrade prompts and billing links from people whose seat someone else pays for is a judgment call, but pitching a plan change to an employee whose company bought the seat rarely makes sense. Also keep in mind that Apple hasn't documented yet how Group Purchases seats will appear, so don't assume every seat holder looks like a regular purchaser.

The in-app side of Group Purchases isn't documented either. The WWDC session says your app will pass the number of seats into the StoreKit 2 purchase request, that new App Store Server API endpoints will support custom invitation flows, and that group management endpoints will let you look up a customer's groups and a group's members. None of that is in the reference docs yet, so there's nothing to build today beyond making sure your entitlement checks are ready.

If you don't want to sell to groups, open each subscription's Purchase Options and switch multiseat off before October 22. If you do, check which stores each subscription is offered in, decide on pricing, and audit your entitlement code for the .assigned case. Either way, it's a setting you now own rather than one you can ignore.

Sample Project

Want to see this code in action? Check out the complete sample project on GitHub:

View on GitHub

The repository includes a working Xcode project with all the examples from this article, plus unit tests you can run to verify the behavior.