Prepare iOS 27 subscriptions: StoreKit 2, Bundles, and Suites

Apple’s iOS 27 subscription changes give app teams two separate decisions to make: whether their existing purchase flow is ready for Apple’s StoreKit 2 requirements, and whether a new Bundle or Suite would fit the way they sell access across products. The new options are not available yet; Apple says Bundles and Suites will arrive later this year on iOS 27, iPadOS 27, macOS 27, and tvOS 27 or later.

The preparation work can start now. Apple says apps should use StoreKit 2 to handle Apple In-App Purchases. Teams interested in Bundles or Suites also need to support Apple’s listed operating-system versions, meet the subscription configuration rules, and request access through Apple’s form. This checklist helps you separate the engineering work from the commercial choice.

First, identify the purchase path you actually ownCopy Anchor Link

Start by listing every way a customer can buy or renew access in your app. Include standalone auto-renewable subscriptions, one-time purchases, subscriptions sold in another app, and any entitlement shared across apps. For each one, record the product identifier, duration, storefronts, renewal behavior, and the code that grants or removes access.

Then mark which purchases are Apple In-App Purchases. Apple’s new Bundles and Suites capabilities are built around its in-app purchase system. If a product is sold only on the web or through a different payment path, do not assume it can be placed into an Apple Bundle or Suite. Confirm eligibility with Apple before designing around it.

Trace the lifecycle from purchase to entitlement. A user may buy, restore, renew, upgrade, cancel, or lose access after a refund. Your app needs one reliable answer for what content each active subscription enables. Keep that mapping explicit: a successful purchase should grant the intended services, while a lapse or cancellation should update access according to the subscription state you have verified.

Prepare the StoreKit 2 implementationCopy Anchor Link

Apple’s first preparation step is to make sure your app uses StoreKit 2 to handle Apple In-App Purchases. Inventory your current purchase code before you change it. Find where the app loads product information, presents the offer, starts a transaction, verifies transaction data, updates entitlements, and handles transaction changes after the initial purchase.

For each point, identify the source of truth. Product identifiers should map to the right plan or service. Transaction verification should be part of the access decision rather than a UI-only success state. The entitlement layer should tolerate a user installing the app on another device or returning after a period away. Apple’s StoreKit 2 documentation describes APIs for product information, transactions, and subscription access; use the current documentation to validate the specific APIs and behavior your app needs.

Next, test more than the happy path. Check a new purchase, a restore or cross-device return, a renewal, a cancellation, an upgrade, and a transaction that does not complete. Verify that the interface and the protected feature agree about access. If your existing implementation uses an older purchase flow, map its current behavior first so that a StoreKit 2 migration preserves product identifiers, customer entitlements, and support workflows.

Decide whether a Bundle fitsCopy Anchor Link

A Bundle combines multiple auto-renewable subscriptions into one purchase. Apple says the configuration can cover multiple subscriptions inside one app, across several apps from the same developer, or across multiple developers’ apps. The multi-developer option can include up to five developers. Apple’s requirements page says a Bundle can include up to five subscriptions, and the subscriptions included in a Bundle need the same duration.

A Bundle is worth evaluating when customers already want two or more related subscription services together. Examples include separate content areas inside one app, companion apps from the same developer, or a partnership where each developer contributes a distinct service. The commercial question is whether a combined offer gives a customer a clear reason to buy more than one service, while still leaving a sensible way to keep or cancel individual subscriptions.

Before requesting access, write down which subscriptions would be included, who owns each app, and whether the durations match. For a multi-developer Bundle, confirm that every partner is willing to submit an interest form and complete Apple’s required program addendum and intake steps. The additional parties and configuration work make this a partnership decision as well as an app change.

Decide whether a Suite fitsCopy Anchor Link

A Suite is a different shape: one subscription provides access across a developer’s set of apps. Apple’s requirements page says a Suite can span up to 15 apps. This may fit a developer with several distinct products that are parts of one broader offering, such as related productivity tools. It is less natural when each app serves a different audience or is bought for a separate job.

Compare a Suite with a Bundle by asking what the customer thinks they are buying. With a Bundle, multiple subscription services are combined in one purchase. With a Suite, the customer buys one subscription that works across a group of the developer’s apps. Map the product catalog and the access rules before choosing: list which apps participate, what each app enables, and how a customer’s existing access should behave if they join or leave the offer.

Do not treat either format as a new app-level payment processor. Apple provides the purchase experience, but your apps still need to recognize transactions and apply the right entitlements to their own content. Write down the subscription-to-app mapping before you submit a request so the product configuration and the shipped access logic agree.

Check requirements and request accessCopy Anchor Link

Before you plan a release around these offers, check the requirements Apple currently lists:

• Use StoreKit 2 to merchandise and process Apple In-App Purchases in the app.
• Support iOS 27, iPadOS 27, macOS 27, or tvOS 27 or later for customers to purchase Bundles and Suites on those platforms.
• For a Bundle, use the same subscription duration for each included auto-renewable subscription.
• Decide whether the offer is a Bundle or a Suite and map every participating subscription and app.
• For a multi-developer Bundle, coordinate the participating developers’ interest forms and Apple’s additional program paperwork.

Apple says developers who want to offer Bundles or Suites should submit a request form describing their app and services. Approval is required; Apple then works with the developer to complete configuration, including subscription details and confirmation of pricing and a go-live date. Apple also says configurations are published in batches. Treat the form as the start of a review and setup process, not as an instant switch you can turn on for launch day.

The announcement gives no specific public availability date beyond “later this year.” Build your plan around that wording. You can audit StoreKit 2, define the offer, and test entitlements now; keep the launch date and any pricing commitments provisional until Apple approves the request and confirms the configuration schedule.

Keep the app and offer testableCopy Anchor Link

Create test cases for each participating app and each subscription state. A Bundle or Suite should not leave one app granting access while another rejects the same customer without an intentional product rule. Test initial purchase, restore, renewal, cancellation, upgrade, and removal of access on each app that participates. Include customers who already hold an individual subscription if your offer will include that service; Apple describes an upgrade path for a customer who purchases a Bundle that includes a subscription they already own.

Keep purchase presentation and entitlement rules separate enough that you can change the merchandising without rewriting access checks throughout the app. Record which products are grouped together, which app owns each feature, and where transaction state is verified. That makes it easier to review the offer with product, engineering, and support before you send Apple a request.

If the app was generated with a starter kit, inspect the delivered code before assuming it contains subscription or payment support. OTF’s SaaS Dashboard customization guide documents how to add Stripe Checkout and a webhook; those are optional integrations, not shipped product billing, and they do not implement Apple In-App Purchases. See the SaaS Dashboard billing and customization guide for that separate web-payment scope.

For the broader submission timeline and device checks, see the App Store submission checklist for AI-built apps. That guide covers general review preparation; this page focuses on StoreKit 2, subscription grouping, and Apple’s access-request process.

SourcesCopy Anchor Link

• Apple Developer News: Get your subscriptions ready for iOS 27, September 16, 2026; checked October 9, 2026.
• Apple Developer: Bundles and Suites for auto-renewable subscriptions, checked October 9, 2026.
• Apple Developer: StoreKit 2, checked October 9, 2026.