For fifteen years an app subscription has meant one thing: one person, one Apple or Google account, one monthly charge, and a support inbox full of "can my colleague use my login?". Within two weeks of each other, both stores announced that this model is getting company. Apple published Get your subscriptions ready for iOS 27 on 16 September, and Google answered on 29 September with The next era of subscriptions. Read side by side, they tell the same story: your subscription can now be bought by a team, by a whole organisation, or as part of a bundle with other apps, some of them not even yours.
Seats, or how your colleague finally gets a legal login
On the Apple side, multiseat purchases come in two flavours. With Volume Purchasing, a company or school that uses Apple Business or Apple School Manager buys a batch of seats in one go and hands them out through its device management tool, a bit like it already does with apps; that launches on 22 October. With Group Purchases, an ordinary subscriber buys several seats in your app and invites the others, and Apple takes care of the invitation and the seat assignment, so you do not have to build a little HR department inside your settings screen. That one arrives "this winter", which in Apple's calendar can mean anything from December to the first daffodils.
The detail that deserves a coffee: multiseat is switched on by default. Subscriptions created before 14 September that do not use StoreKit 2, or that have Family Sharing on, start opted out, but everything else is already for sale in bulk unless you change it in App Store Connect. In the WWDC26 session on groups Apple also shows volume pricing, up to five price bands with a cheaper seat for bigger orders, which is the kind of decision your finance person will want to make, not discover.
Google is heading the same way with multi-quantity subscriptions, aimed squarely at productivity, education and AI apps that sell to teams and classrooms. The difference is the timing: in Google's post this one, like most of the list, is still being tested with selected partners through an early access programme, so for now it is something to plan for rather than to switch on.
The diagram shows the same subscription sold four ways. First, one person buys it for themselves, as today. Then a subscriber buys five seats and invites their team. Then a company buys seats in bulk and its IT department assigns them to devices. Finally, one purchase unlocks several apps at once, as a bundle or a suite.
Bundles, and the friends you did not know you had
The second idea is selling several things as one. Apple's Bundles and Suites let a Bundle combine up to five subscriptions, from your own apps or from up to five different developers who sign a joint addendum, while a Suite is one subscription that opens up to fifteen of your own apps. They arrive later this year with iOS 27, you ask for access through a form, and all the subscriptions in a Bundle must share the same duration (monthly with monthly, yearly with yearly). Google lists the same idea as cross-developer bundling, plus mixed carts that sell a subscription and a one-time product in a single checkout, both still in testing. So if a meditation app and a running app ever wanted to get married, the stores are now printing the invitations.
The part that is already live on Android
One item in Google's post is available to every developer right now: the in-app messaging API. When a payment fails or a price increase is waiting for the user's agreement, Google Play shows a short message inside your app with a button to sort it out, instead of letting the subscription quietly slip away. Google recommends calling it each time the user opens the app, and it costs about ten lines:
val params = InAppMessageParams.newBuilder()
.addInAppMessageCategoryToShow(InAppMessageCategoryId.TRANSACTIONAL)
.build()
billingClient.showInAppMessages(activity, params) { result ->
if (result.responseCode == InAppMessageResponseCode.SUBSCRIPTION_STATUS_UPDATED) {
// Payment fixed or price increase accepted: refresh the status on your server
refreshSubscription(result.purchaseToken)
}
}
Ten lines to keep subscribers whose card simply expired: as returns on investment go, it is hard to beat.
Why "StoreKit 2" keeps coming up
Every one of Apple's new options requires StoreKit 2, and there is a sneaky reason your code may not be ready even if it does use it. The colleague who accepts a group invitation, or the employee whose phone receives a seat from IT, never tapped "Subscribe" in your app. If your app unlocks premium by saving a flag right after a purchase, those people will see your paywall, staring at it while their company has already paid. The safe habit is to ask StoreKit what the user is entitled to, every launch:
import StoreKit
/// The active subscription among the given products, however it reached this user:
/// bought here, a seat from a group or a company, or another device.
func activeSubscription(among productIDs: Set<String>) async -> String? {
for await result in Transaction.currentEntitlements {
guard case .verified(let transaction) = result,
productIDs.contains(transaction.productID),
transaction.revocationDate == nil else { continue }
return transaction.productID
}
return nil
}
If your app still runs on the original StoreKit API, this autumn is a good excuse to move, because that is the ticket to all of the above.
So what would I actually do?
This week I would open App Store Connect and decide, subscription by subscription, whether bulk sales make sense, rather than leaving the default to decide for me. On Android I would add the in-app messaging call, since it is live and cheap. Then I would check that access comes from entitlements and not from a purchase screen, test it with a second account, and keep a calendar note for 22 October. Bundles can wait for a good partner, but the paperwork takes time, so it is worth a first chat if a natural one comes to mind. And if you are also thinking of selling AI features to teams, the seat question will come up sooner than you think.
If you want help
Billing code is the kind you only want to touch once, carefully. Keeping an app in line with what the stores ask for is what the App Store and Google Play compliance page is about, and if you would rather first know where your StoreKit and Play Billing code stands, the mobile app health check looks at exactly that.
Sources: Apple Developer News, 16 September 2026, Bundles and Suites, Manage purchase options for an auto-renewable subscription, Offer subscriptions to groups and organizations (WWDC26), Android Developers Blog, 29 September 2026, About subscriptions, Google Play Billing.