---
title: "Apple Subscription Bundles and Suites: Should You Apply?"
author: "Nate Laquis"
author_role: "Founder & CEO"
date: "2026-10-28"
category: "How to Build"
tags:
  - Apple subscription bundles
  - App Store subscription suites
  - StoreKit 2
  - iOS 27 subscriptions
  - app monetization
excerpt: "Apple will let you sell several subscriptions as one In-App Purchase, or one subscription across many apps. The rules are published, but pricing and revenue share are not. Here is how to decide whether to apply."
reading_time: "11 min read"
canonical_url: "https://kanopylabs.com/blog/apple-subscription-bundles-and-suites-ios-27-should-you-apply"
---

# Apple Subscription Bundles and Suites: Should You Apply?

## What Apple Announced

On September 16, 2026, Apple told developers to get their subscriptions ready for iOS 27. Two of the headline items are **Bundles** and **Suites**. Both let a customer buy more than one thing through a single In-App Purchase, and both are due later this year on iOS 27, iPadOS 27, macOS 27 and tvOS 27 or later.

A Bundle packages several auto-renewable subscriptions into one purchase. A Suite is the reverse shape: one subscription that works across a set of apps from the same developer. Apple runs the purchase screen and lists every app included, so you do not build that merchandising yourself.

I am working from Apple's own developer news post and its Bundles and Suites page, not from rumor. That matters this month, because a lot of third-party coverage of Apple's fall announcements has been loose with dates and details. Where Apple has not published something, I will say so rather than guess. And the most important thing Apple has not published is also the thing you most want to know: what the pricing rules are and what Apple takes.

If you run a single app with a single subscription, most of this is not for you yet. If you run two or more apps, or you sell a subscription that sits next to someone else's, read on. This is the first time Apple has built the plumbing for it.

![Hand holding an iPhone showing an app on screen](https://images.unsplash.com/photo-1512941937669-90a1b58e7e9c?w=800&q=80)

## Bundles and Suites, Defined Properly

The two names sound alike, so here are the exact definitions from Apple's page.

- **Single-developer Bundle:** multiple auto-renewable subscriptions from one Apple Developer account, sold as one purchase. They can live in one app or across several of your apps.

- **Multi-developer Bundle:** subscriptions from different developers' apps, sold together. Up to five developers can take part.

- **Suite:** one purchase that gives access to content across multiple apps from a single developer.

The practical difference is how many subscription products exist behind the scenes. In a Bundle, each included subscription is still its own product, and the customer gets all of them at once. In a Suite, there is one subscription, and your apps all recognize it.

Here are the limits Apple lists. A Bundle holds up to 5 subscriptions. A Suite covers up to 15 apps. A multi-developer Bundle has up to 5 developers. Every subscription inside a Bundle must have the same duration, so you cannot mix a monthly plan and an annual plan in one Bundle.

That last rule bites more teams than you would expect. If your product has a monthly plan and a partner's has an annual one, a multi-developer Bundle does not work until one of you adds a matching duration. Check this before you spend a week in meetings about revenue split.

## What Apple Has Not Told You

Apple's Bundles and Suites page is plain about what it leaves out. It does not specify pricing or discount rules, including any minimum or maximum discount. It does not give a revenue share or commission rate for Bundles, and it does not say how money is divided between developers in a multi-developer Bundle. It gives no launch date beyond saying Bundles and Suites are configured and published in batches.

So today you cannot build a financial model for a Bundle with confidence. You can build a model with ranges and a list of questions to put to Apple.

Here are the questions I would write down before filling in the request form:

- What is the commission on a Bundle sale, and does the first-year versus second-year rate apply per subscription or per Bundle?

- How is a multi-developer Bundle's revenue split, who sets the split, and who handles tax and refunds on each side?

- Is there a floor or ceiling on the Bundle discount?

- If a customer already pays for one of the included subscriptions, what happens to your reporting and to your churn numbers when they move into a Bundle?

- What data do you get on a Bundle subscriber? Can you identify them as yours in the same way you identify a standalone subscriber?

The answers decide whether a Bundle is a growth tool or a discount that eats margin. I have seen founders skip this step on other pricing changes, ship the offer, and then find out in the first payout report that the numbers did not match their spreadsheet. Get the terms in writing before you commit marketing spend. Our piece on [Apple's multiseat subscriptions](/blog/apple-multiseat-subscriptions-default-on-app-store-connect-b2b-pricing) covers a sibling change from the same announcement, and the same lesson applies: read the defaults before they read you.

## The Requirements You Can Plan Around

The technical side is documented, and it is short. To take part you need three things.

1. **Apple In-App Purchases.** Bundles and Suites are for subscriptions sold through Apple. If you bill on the web with Stripe and only switch on features in the app, there is nothing to bundle on Apple's side.

2. **StoreKit 2.** Apple says to use the StoreKit 2 framework to merchandise and process purchases. If your app still runs on the original StoreKit APIs, this is the real project.

3. **iOS 27 and the matching OS versions.** People on earlier OS versions cannot buy Bundles or Suites. Your app can keep supporting older systems, but those users will not see the bundled offer.

The StoreKit 2 requirement is the one to look at first. StoreKit 2 uses async/await, returns signed transaction data you can verify on your device, and changes how you check entitlements. Moving from the old receipt-based flow to StoreKit 2 is usually a few weeks of work for a mid-size app, mostly in testing the edge cases: restored purchases, family sharing, refunds, grace periods and billing retry. Budget the testing, not the code.

Apple also recommends using introductory and promotional offers to create discounted Bundle and Suite prices, and using the Retention Messaging API now, with App Store Connect configuration of retention messages expected later this year. Both point the same way. Apple expects the discount to be built from tools you already have, not from a new pricing field. If you have never shipped an introductory offer, build that muscle first.

If you want the background on the subscription plumbing itself, start with [how to implement subscription billing](/blog/how-to-implement-subscription-billing).

## How Access Works

This is not a toggle in App Store Connect. You request access, and Apple decides.

1. You submit a request form describing your app and the services you want to bundle.

2. If Apple approves, you get an email. Apple then works with you to collect subscription details and confirm pricing and a go-live date.

3. For a multi-developer Bundle, every developer submits an interest form, signs a Multi-Developer Bundle Program Legal Addendum, and files an intake form with subscription details before any configuration starts.

4. Bundles and Suites are set up and published in batches, and Apple tells you when yours is done.

Notice the phrase "confirm pricing." Pricing is worked out with Apple on a case-by-case basis, at least for now. That fits with the missing pricing rules on the public page. It also means timing is partly out of your hands. If you want a Bundle live for a spring campaign, the request goes in this quarter, not next.

The multi-developer path adds a legal step. A signed addendum between you and Apple, plus whatever you agree with your partners, means you should bring a lawyer in early. Do not let the engineering team discover the paperwork two weeks before launch.

![Laptop screen showing subscription revenue charts and analytics](https://images.unsplash.com/photo-1551288049-bebda4e38f71?w=800&q=80)

## What Happens to Your Existing Subscribers

Apple spells out the customer side, and it is friendlier than I expected. If someone with a standalone subscription upgrades to a Bundle, they get immediate access to every subscription in it and a prorated refund for the remainder of the standalone period. A customer can cancel the whole Bundle, or keep individual subscriptions through their Apple Account. Cancellations and partial changes take effect at the next renewal, while upgrades take effect immediately.

Three consequences follow for your product and your metrics.

### Your entitlement logic must handle partial states

A customer can drop out of a Bundle and keep one piece. Your app has to read the current entitlements and not assume that someone who arrived through a Bundle leaves through one. Test the path where a user cancels two of three Bundle subscriptions and keeps the third.

### Your churn and revenue reporting will shift

A prorated refund on the standalone plan shows up as refunded revenue, while the Bundle shows up as a new subscription. Your finance dashboard will briefly look worse before it looks better. Tell whoever reads that dashboard before it happens.

### Upgrades are instant, downgrades are not

That asymmetry is good for conversion. A customer who says yes gets the product right away. It is a reason to put the Bundle offer at the moment of highest intent, such as a paywall after a successful first use, not in a settings menu. Our guide to [building a subscription app with paywalls](/blog/how-to-build-a-subscription-app-with-paywalls) covers where that moment tends to be.

## Who Should Apply Now, and Who Should Wait

Here is my honest read, by situation.

### Apply now if you have two or more apps

If you sell, say, a planner and a notes app to the same kind of customer, a Suite or single-developer Bundle is the cleanest upgrade path you have had. One purchase, one price, one place to cancel. The cross-sell is built into the App Store instead of something you bolt on. Apple's request form is a conversation, not a commitment, so there is little downside to starting it.

### Apply now if you have a natural partner

A multi-developer Bundle makes sense when two products serve the same customer and neither competes with the other. Think a meditation app and a sleep tracker, or a language app and a travel app. The pairing has to be real. Customers can tell when two unrelated apps were stapled together to chase a discount.

### Wait if you have one app and one plan

You have nothing to bundle. Spend the time on StoreKit 2, introductory offers and your paywall instead. All three are required groundwork if you add a second product later.

### Wait if you bill outside Apple

If most of your revenue runs through web checkout, Bundles and Suites do not touch it. Your own pricing page can already offer a bundle with no Apple approval.

### Wait if your plan durations do not match

Every subscription in a Bundle needs the same duration. If your partner sells annual plans and you sell monthly, fix that first.

## A Pre-Application Checklist

Whether you apply this week or next quarter, this is the work to do in the meantime. It is useful even if Apple turns you down.

1. **Audit your StoreKit version.** If you are on the original APIs, schedule the StoreKit 2 migration and plan a full regression pass on purchase, restore, refund and grace period flows.

2. **Line up plan durations.** Decide which duration each product will offer, since all subscriptions in a Bundle must match.

3. **Ship an introductory offer.** Apple points to introductory and promotional offers as the way to price a Bundle. Having one live proves your pipeline works.

4. **Write down your floor price.** Decide the lowest net revenue per customer you would accept from a Bundle after Apple's cut, so you can say no to a bad deal quickly.

5. **Check your minimum OS.** Know what share of your active users will be on iOS 27 by spring. Only they can buy a Bundle.

6. **Map your entitlement logic.** List every place your app checks whether a user is subscribed, and make sure each one reads from one source of truth.

7. **Plan for the April 2027 SDK deadline.** Apple will require builds with the iOS 27 SDK or later from April 2027, so you will be on the new SDK anyway. Our [iOS 27 SDK deadline plan](/blog/apple-ios-27-minimum-sdk-deadline-app-update-plan) covers the update schedule.

Most of that list is ordinary subscription hygiene. The reason to do it now is that Apple will ask about your setup in the request, and having crisp answers moves the conversation faster.

![Desk with laptop and notebook where a team plans an app pricing strategy](https://images.unsplash.com/photo-1460925895917-afdab827c52f?w=800&q=80)

## How I Would Think About the Economics

Since Apple has not published the commission or discount rules, here is the framework I use for any bundle, on Apple or anywhere else.

### Start with the customer who already pays

A Bundle is cheaper than buying each subscription alone, so every existing customer who moves over lowers your revenue from them. The question is whether the Bundle brings in enough new subscribers, or keeps enough customers who would have cancelled, to make up the difference. If your standalone churn is already low, the Bundle is mostly a discount. If your churn is high, a Bundle that adds a second reason to stay can pay for itself.

### Measure in lifetime value, not monthly price

Say a customer pays you a given amount per month and stays for a certain number of months. A Bundle that cuts the monthly price by a fifth but extends the average stay by a third comes out ahead. One that cuts the price and leaves the stay unchanged does not. You will not know which you have until you run it, which is why a small, time-boxed test beats a full launch.

### Treat the partner's customers as the prize

In a multi-developer Bundle, the real value is access to someone else's audience. A partner with a loyal user base and a product that fits yours is worth more than a larger partner with a weak fit. Ask what share of their subscribers use a product like yours today.

### Keep an exit

Any Bundle should have a review date. If the numbers do not work after two or three renewal cycles, you need a clean way to end it without surprising the customers already in it. Ask Apple what the wind-down looks like before you sign anything.

The same thinking applies to any change in how you charge. The vendor sets the terms, you read them closely, and you keep your own pricing model flexible enough to change when the terms do. We made a similar argument about [subscription billing design](/blog/how-to-implement-subscription-billing) in general.

## What I Would Do This Quarter

If you have a multi-app portfolio, submit Apple's request form now and use the conversation to get the missing numbers: commission, discount limits and revenue split. A reply costs you nothing, and the answers shape every decision after it.

In parallel, finish your move to StoreKit 2 and ship an introductory offer if you do not have one. Those two items are required for Bundles and Suites, and they are good for your business without them.

If you have one app, skip the request for now. Put the effort into your paywall, your offers and your upgrade path to iOS 27, and revisit when Apple publishes pricing rules and the first developers report real results. Early adopters on a new Apple program usually get both the best placement and the roughest edges. Pick the side of that trade that fits your appetite for risk.

Either way, treat the subscription layer as something you will change again in twelve months. Apple has moved quickly on subscriptions this year, from multiseat purchasing to Bundles and Suites, and the teams that adapt fastest are the ones whose billing code is clean. If you want a second pair of eyes on your StoreKit setup or a plan for bundling across your apps, [book a free strategy call](/get-started).

---

*Originally published on [Kanopy Labs](https://kanopylabs.com/blog/apple-subscription-bundles-and-suites-ios-27-should-you-apply)*