App Store multiseat subscriptions are now on by default. Decide before 22 October.App Store multiseat subscriptions are now on by default. Decide before 22 October.

Apple enabled multiseat purchasing by default for auto-renewable subscriptions in App Store Connect on 16 September.

Multiseat covers two ways of buying several seats at once. Volume Purchasing, which launches on 22 October 2026, lets organisations using Apple Business or Apple School Manager buy a subscription in bulk and assign seats through their device management provider. Group Purchases, due this winter, let one subscriber buy several seats inside the app and invite others, with Apple handling the invitations and seat assignment. Developers can switch multiseat off entirely, or choose separately whether it is offered on the App Store, Apple Business and Apple School Manager.

Apple's WWDC session on the feature adds several details. StoreKit 2 is required. Once a seat is assigned, the App Store issues a transaction for each member. Subscriptions with Family Sharing start opted out. Volume pricing can have up to five price bands. Apps that already manage their own teams can use new App Store Server API endpoints in place of Apple's invitation flow. MacRumors reported the programme and its timing when it was announced in June.

What on by default means for existing apps

Every client subscription we look after is now available to buy in bulk, unless someone opts it out. Nobody on those projects chose that. For many apps it is a free new sales channel. For some it is a problem, and the ones most at risk are the ones already selling team plans some other way.

Where it can go wrong

• Apps still on the original StoreKit. Apple says StoreKit 2 is required and does not say what happens to an older app that has multiseat switched on. Until the migration is done, we would switch it off.
• Backends that tie a subscription to the buyer's account. A member's seat arrives as a separate transaction. If the server assumes whoever paid is the only person entitled, members will pay nothing and see a paywall.
• Products that already sell teams on the web. Two places can now create a team, and they will disagree about who is in it. Either connect them through the new server endpoints or keep multiseat off in-app.
• Pricing. Apple's help pages treat multiseat price rises differently: beyond the first seat, a group buyer must consent if the total rises by more than half. A client planning a price change should know that before seats are sold.

A sales channel nobody chose is still a sales channel you support.

Bundles and Suites are a separate decision

The same post invites developers to request Bundles and Suites, due later this year on the 27 releases. A Bundle can combine up to five subscriptions, including subscriptions from up to five different developers. A Suite covers one developer's subscription across as many as fifteen apps. Both need StoreKit 2 and the 27 releases for purchase. Access is by request, and Apple sets them up in batches.

For most of our clients this is irrelevant: they have one app. It matters for the few with a family of apps and one account system. For them a Suite is worth asking about now, because a batched onboarding process does not bend to a launch date.

The check we are running this week

For every client subscription, we write down four answers. Does the app use StoreKit 2? Does the backend grant access per transaction, or per purchaser? Is there a team model outside the App Store? And does the client want to sell to organisations at all? Four yes-or-no answers settle whether multiseat stays on, and they need to be settled before 22 October, when the first organisations can actually buy.

Where the answers are all comfortable, leaving it on costs nothing and may bring in a business customer nobody went looking for. Where any of them is uncertain, turning it off takes a minute and can be undone once the work is done.