StoreKit commitment plans in 2026: sell a year, bill monthly, in all but 2 markets

Summary. Apple announced monthly subscriptions with a 12-month commitment on 27 April 2026 and shipped them with iOS 26.5, iPadOS 26.5, macOS Tahoe 26.5, tvOS 26.5 and visionOS 26.5 in May 2026. Customers need 26.4 or later to see them. Two markets are excluded: the United States and Singapore. Everywhere else, including India, you can list a one-year auto-renewable subscription and let the customer pay it in twelve monthly instalments while committing to the full term. On the API side, Product.SubscriptionInfo gains a pricingTerms array; every auto-renewable subscription carries at least one billing plan with a default billingPlanType of .upFront, and .monthly appears only on 12-month commitment plans. Transactions with .upFront return nil for commitmentInfo; .monthly transactions return commitment progress, price and expiration. These fields start at OS 26.4. If you list at $119.88 a year, the customer can instead pay twelve times $9.99, and you get the annual retention profile at the monthly price point.

One correction worth making up front, because it is circulating widely: this is not an iOS 27 feature. It arrived in the 26.5 cycle, four months before iOS 27 ships, and any app built against the iOS 26.4 SDK or later can adopt it today.

What actually shipped

The mechanic is simple and the customer-facing detail is where the product decision lives. A person selects the monthly billing plan on a one-year subscription. They pay monthly. They are committed to the full year of payments. They can cancel at any time, and cancelling prevents the subscription from renewing after they have completed the agreed payments that fulfil the commitment.

Apple built transparency into the account layer rather than leaving it to your app. Customers can see the number of completed and remaining payments in their Apple Account. Apple sends an email, and a push notification if the customer opted in, ahead of each renewal date to remind them of the upcoming charge.

That matters for your support load. The single largest complaint category for instalment billing is "I did not know I would be charged again", and on this mechanism Apple owns that notification, not you.

The API surface you have to handle

Three properties change what your merchandising and entitlement code has to do.

pricingTerms on Product.SubscriptionInfo lists all available billing plans for a product. This is the merchandising input. If you hard-code a single price string from Product.displayPrice, your paywall will show the wrong thing the moment a product carries two plans, so read the array and render both options.

billingPlanType distinguishes them. Every auto-renewable subscription carries at least one plan with a default of .upFront. A value of .monthly applies only to a monthly subscription with a 12-month commitment. Treat .upFront as the case you already handle and .monthly as the new branch.

commitmentInfo carries the state that matters for support and entitlement. On an .upFront transaction it is nil. On a .monthly transaction it returns the progress, price and expiration for the 12-month commitment. Product.SubscriptionInfo.RenewalInfo exposes renewalBillingPlanType and commitmentInfo for the renewal of the overall commitment, which is where you find out whether the customer will roll into another committed year or fall back.

The fields are available starting with OS 26.4, so every read needs an availability check. A rough shape:

            if #available(iOS 26.4, macOS 26.4, tvOS 26.4, visionOS 26.4, *) {
    for term in product.subscription?.pricingTerms ?? [] {
        switch term.billingPlanType {
        case .monthly:
            // Render "12 months, billed monthly" alongside the up-front option.
            presentCommitmentOption(term)
        default:
            presentUpFrontOption(term)
        }
    }
} else {
    presentUpFrontOption(defaultTerm)
}
          

For entitlement, do not infer term length from the price paid. Read commitmentInfo from the transaction and, where you mirror state on your own backend, store the commitment progress and expiration rather than recomputing them from renewal dates. A customer eleven payments into a commitment and a customer on their eleventh consecutive monthly renewal look identical if you only look at renewal count.

Should you offer it?

The commercial case is straightforward and the counter-case is usually ignored.

The case for. A twelve-payment plan lowers the entry price to the monthly figure while giving you a twelve-month contracted relationship. In price-sensitive markets that gap between a monthly price point and an annual cash outlay is the single biggest conversion barrier on a paywall. You also get predictable revenue per cohort rather than a monthly churn curve.

The case against. You are underwriting a year of service for a customer who has paid one month, and Apple's mechanism does not give you a way to suspend access if a later payment fails; the subscription simply does not renew after the agreed payments are complete. If your marginal cost per user per month is meaningful, which it is for anything running inference, video transcoding or human support, the payment schedule matters to your cash position in a way it does not for a pure software product.

There is also a discount question. An annual plan usually carries a discount against twelve monthly payments, because the customer is prepaying. A commitment plan removes the prepayment while keeping the term. Setting the monthly commitment price equal to your standard monthly price and keeping the annual discount on the up-front plan gives customers a coherent three-way choice. Setting it equal to one-twelfth of the discounted annual price gives away the prepayment discount without receiving the prepayment.

Testing and rollout

You can configure this subscription type in App Store Connect and test it in Xcode. Two rollout details save time.

Availability is a matrix, not a flag. The plan is unavailable in the United States and Singapore, and invisible to customers below 26.4. Your paywall therefore has three states to design for, not two: the option shown, the option hidden by storefront, and the option hidden by OS version. Test all three, and make sure the hidden states do not leave a gap in your layout.

Do not gate the migration on iOS 27. Because the feature is a 26.x capability, waiting for the September iOS 27 cycle to adopt it costs you a full quarter. If your app is already going through the iOS 27 API changes and testing checklist, add the pricingTerms branch to that work rather than scheduling it separately.

India-specific considerations

India is not excluded, and it is close to the ideal market for this mechanism. Monthly price points convert where annual outlays do not, and the commitment plan keeps the annual term while removing the cash barrier.

Two local realities shape the implementation. First, the installed-base constraint is real: your paywall has to degrade cleanly for customers below OS 26.4, and in India that tail is longer than in the markets Apple designs paywalls for. Instrument the share of paywall impressions that can actually see the option before you judge the experiment.

Second, this is a payment mechanism, so the standard Indian subscription-billing questions apply to how you communicate it, not to how it is collected. Apple handles the collection and the renewal reminders, which removes the recurring-mandate problem you would face collecting outside the App Store. If you are also running a web or Android billing path, the commitment plan will not exist there, and you need to decide whether to keep pricing parity or let the iOS offer diverge. Our app subscription billing and monetisation guidance covers running those paths together.

For teams that also sell through external purchase links in the European Union, note that those flows are a separate mechanism with separate rules; see the iOS external purchase links StoreKit guide.

Three failure modes we expect to see

The mechanism is new enough that the common mistakes have not been written up yet, so here are the three that follow directly from how the API is shaped.

Deriving term length from renewal history. A customer on their eleventh consecutive monthly renewal and a customer eleven payments into a twelve-payment commitment produce a similar-looking sequence of renewal events. If your backend infers "this person is on a monthly plan" from that sequence, your retention analytics will misclassify committed customers as monthly churn risks, and your win-back campaigns will target people who are contractually still with you. Persist commitmentInfo explicitly.

Treating the storefront exclusion as a bug. The option is genuinely absent in the United States and Singapore. A paywall that renders a blank slot, an empty comparison column, or a "loading" state for those customers looks broken rather than intentional. Design the two-option layout as a first-class state, not as a degraded version of the three-option one.

Reading conversion without an eligibility denominator. If you compare paywall conversion before and after adding the plan, and a large share of your traffic is on an OS below 26.4 or in an excluded storefront, the aggregate number will understate the effect and you may kill a working experiment. Segment on eligibility first, then measure.

How this fits the rest of your subscription surface

Commitment plans sit alongside the offer types you already run rather than replacing them. Introductory offers, promotional offers and offer codes continue to apply to the underlying subscription, and the billing plan is a separate axis from the offer. That means your paywall logic now has two dimensions to reason about: which offer applies to this customer, and which billing plans are available for this product in this storefront on this OS version.

Keep the resulting matrix small on purpose. A paywall presenting an introductory offer, a promotional offer, an up-front annual plan, a committed monthly plan and a standard monthly plan simultaneously is not a pricing strategy; it is a decision the customer will resolve by leaving. Two or three clearly differentiated choices convert better than five, and the commitment plan earns its slot only if it displaces something rather than adding to the pile.

If you are planning wider work on the iOS 26 to 27 transition, the billing-plan branch belongs in the same release as your other StoreKit changes. Our Xcode 27 and Swift 6.4 developer features guide and the iOS 27 enterprise fleet readiness guide cover what else is landing in that window.

What to do this sprint

Read pricingTerms instead of a single display price on every paywall surface. This is the change that unblocks everything else.

Add a .monthly branch to entitlement handling and persist commitmentInfo progress and expiration on your backend, rather than deriving term state from renewal counts.

Design the three paywall states, then screenshot each one on device. Storefront-hidden and OS-hidden are different bugs and they look the same in a simulator with default settings.

Price the commitment plan deliberately. Decide whether it carries the annual discount or the monthly rate, and write down why, because the answer determines whether the feature adds revenue or moves it.

Instrument eligible impressions before conversion. A flat result on a plan that only 30% of your traffic could see is not a flat result.

FAQ

How eCorpIT can help

eCorpIT builds and monetises iOS applications from Gurugram with senior-led engineering teams. For subscription work we implement the StoreKit 2 billing-plan surface end to end, design paywalls that degrade correctly across storefront and OS-version eligibility, wire commitment state into backend entitlement so support can answer "how many payments are left", and instrument eligible-impression conversion so pricing experiments produce readable results. We are ISO 27001:2022 certified, CMMI Level 5 appraised and MSME certified. To review your subscription architecture, contact us.

References

1. Now Available: Monthly Subscriptions with a 12-Month Commitment - Apple Developer, 27 April 2026

1. Supporting monthly subscriptions with a 12-month commitment - Apple Developer Documentation

1. Managing the life cycle of monthly subscriptions with a 12-month commitment - Apple Developer Documentation

1. Product.SubscriptionInfo.BillingPlanType - Apple Developer Documentation

1. Product.SubscriptionInfo.RenewalInfo - Apple Developer Documentation

1. Subscriptions and offers - Apple Developer Documentation

1. What's new in Apple In-App Purchase, WWDC26 session 210 - Apple Developer

1. Auto-renewable subscriptions - Apple Developer

1. Offer auto-renewable subscriptions - App Store Connect Help

1. Set up promotional offers for auto-renewable subscriptions - App Store Connect Help

1. Handling subscriptions billing - Apple Developer Documentation

1. Product.SubscriptionInfo.RenewalState - Apple Developer Documentation

1. StoreKit framework - Apple Developer Documentation

1. StoreKit 2 - Apple Developer

1. App Store Small Business Program - Apple Developer

Last updated: 14 August 2026.