Sell the Year, Bill the Month: Apple’s StoreKit Commitment Plans
Muhammad Tayyab

Apple’s monthly subscription with a 12-month commitment lets customers pay monthly while committing to a full year on a one-year auto-renewable product. It is a billing plan on an existing annual SKU — not a new product type — with StoreKit pricingTerms, commitmentInfo, and Server Notifications V2 lifecycle hooks.
Apple’s monthly subscription with a 12-month commitment lets customers pay month by month while committing to a full year on a one-year auto-renewable product. It is a billing plan on an existing annual SKU — not a new product type — wired through StoreKit pricingTerms, commitmentInfo, and App Store Server Notifications V2.
If you have shipped subscriptions on the App Store for any length of time, you already know the classic tradeoff: annual converts fewer people but pays you once and holds retention for a year; monthly converts more easily and churns harder. Apple’s “monthly with a 12-month commitment” plan sits between those poles: merchandise the year, collect like the month.
This post walks through what it is, how the APIs and App Store Connect setup work, how cancellations and refunds behave, and when an indie should enable it versus sticking with classic annual or free-roaming monthly. Official behavior is cited from Apple’s StoreKit docs and WWDC26 session What’s new in Apple In-App Purchase. Industry context (cashflow, market exclusions, psychology) is labeled as such.
Related reading on this site: The App Store Review Process: What Nobody Tells You.
What “sell the year, bill the month” actually is
Per Apple’s documentation (Supporting monthly subscriptions with a 12-month commitment), a monthly subscription with a 12-month commitment is an auto-renewable subscription that bills monthly and has a yearly commitment. After all twelve payments complete, the commitment renews for another twelve months unless the customer cancels before the commitment renewal date.
That is different from a standard annual subscription, which bills once up front for the year. It is also different from a standard monthly subscription, which renews every month with no year-long commitment.
Inside your app, each billing period behaves like a monthly subscription: each period produces an independent transaction and grants about one month of access. The distinction is that the customer has committed to the full year, so billing continues through all twelve periods even if they cancel the commitment renewal early.
Apple’s docs are explicit on product modeling: this is not a new In-App Purchase product type. You configure the monthly billing plan on an existing one-year auto-renewable subscription in App Store Connect. Product ID and subscription group stay the same; you add a second billing plan beside the default up-front annual plan.
Timeline and platform requirements (verify against Apple, not rumor)
Apple’s current documentation states:
- Build with the Xcode 26.5 SDK or later.
- Customers need devices on iOS / iPadOS / macOS / tvOS / visionOS 26.4 or later.
- Availability is worldwide except the United States and Singapore.
WWDC26 session 210 (What’s new in Apple In-App Purchase) describes the capability as introduced with the iOS 26.5 era of shipping, while customer visibility still depends on 26.4+ storefronts and devices. If you see blog posts saying “iOS 26.5 only” without the 26.4 customer floor, treat that as incomplete.
Industry context (not Apple docs): secondary write-ups (for example developer blogs and commerce vendors covering April–May 2026) reported announcement around 27 April 2026 and wider OS rollout in May 2026. Use Apple’s docs and App Store Connect for what you ship; treat those dates as narrative context.
Billing plan types: .upFront vs .monthly
Every auto-renewable subscription carries a Product.SubscriptionInfo.BillingPlanType:
- Plan — StoreKit — JWS / server — Meaning
- Up-front —
.upFront—BILLED_UPFRONT— Classic behavior — bill the period in full when it starts - Monthly commitment —
.monthly—MONTHLY— Monthly installments across a 12-month commitment
SubscriptionInfo.pricingTerms lists available plans for the product. For a one-year subscription with the commitment plan enabled in the customer’s storefront, you typically get two entries: up-front annual and monthly commitment. Standard subscriptions without the plan return only up-front.
Each pricing-terms entry exposes the merchandising fields you need:
billingPlanTypebillingDisplayPrice— what to show for the billing period (monthly amount on the commitment plan)billingPeriodcommitmentInfo— total commitment price and period countsubscriptionOffers— offers that apply to that plan only
Apple requires you to show both the monthly billing price and the total commitment amount before purchase.
App Store Connect setup
High-level flow from Apple’s docs and WWDC26:
- Open the app’s subscriptions in App Store Connect.
- Select a one-year auto-renewable subscription (new or existing).
- Set up availability for monthly with a 12-month commitment.
- Configure monthly price per territory.
- Optionally attach introductory / promotional / win-back offers per billing plan (offers are plan-specific).
Because both plans share one product ID, customers interact with a single subscription SKU that now offers two payment shapes. Plan your subscription group order carefully: upgrades, downgrades, and cross-grades still follow group ranking, with commitment-specific timing rules (below).
Upgrade / downgrade behavior that surprises people
From Apple’s supporting doc:
- Upgrades are immediate. Moving from a commitment plan to a higher-tier subscription ends the commitment now; the customer may get a prorated refund for the unused portion of the current period.
- Downgrades are deferred. A lower-tier choice takes effect at the end of the current 12-month commitment. Monthly billing on the commitment continues until then.
- Cross-grades depend on durations and billing plan types of both sides — check App Store Connect rules before you invent a “self-serve tier ladder” UI.
StoreKit: merchandise, purchase, entitle
Merchandising with StoreKit views or custom UI
WWDC26 shows StoreKit views picking a preferred term:
SubscriptionStoreView(groupID: "YOUR_GROUP_ID") {
// marketing content
}
.preferredSubscriptionPricingTerms { _, subscriptionInfo in
subscriptionInfo.pricingTerms.first {
$0.billingPlanType == .monthly
}
}For custom paywalls, filter pricingTerms for .monthly, then display billingDisplayPrice and commitmentInfo total price. Billing-plan metadata only appears when the plan is available in the customer’s storefront — so US and Singapore customers will not see .monthly terms even if you configured them globally elsewhere.
Purchase
let result = try await product.purchase(options: [.billingPlanType(.monthly)])Same purchase(options:) path you already use; the new option selects the commitment plan. Verify the transaction, unlock access, finish the transaction. Subsequent monthly renewals arrive through Transaction.updates like any other auto-renewable.
Before first subscribe, Apple automatically shows a one-time disclosure sheet per Apple Account explaining payment count and cancellation guidance. You do not build that sheet.
Entitlements: which expiration date?
This is the sharp edge of the API.
- Field — Meaning — Use for
Transaction.expirationDate— End of the current monthly billing period — Entitlement / access checksTransaction.commitmentInfo.expirationDate— End of the full 12-month commitment — Progress UI only
Apple’s note is unambiguous: grant access from the transaction period expiration (plus the usual revocationDate / isUpgraded checks), not from commitment expiration. If you accidentally treat commitment end as “paid through,” you will unlock a year of content after a single monthly charge.
For progress UI, read commitmentInfo on the latest transaction:
billingPeriodNumber(e.g. 2 of 12)totalBillingPeriods(12)expirationDate(commitment end)price(total commitment cost)
commitmentInfo is nil on up-front transactions.
System UI also helps: .manageSubscriptionsSheet / showManageSubscriptions shows remaining payments and commitment renewal timing without you reinventing Account settings.
Server side: App Store Server Notifications V2
Apple’s lifecycle doc (Managing the life cycle of monthly subscriptions with a 12-month commitment) is the companion to the client guide. Practical points for indie backends:
Renewals
Each monthly charge is a real renewal. Expect DID_RENEW at your V2 endpoint and a new signed transaction with billingPlanType: MONTHLY and commitmentInfo (period number, total periods, commitment expiry, commitment price). Process access the same way you would for a standard monthly renewal.
When period 12 completes and willAutoRenew indicates continuation, a new commitment can begin (or the customer may renew into a different plan — read renewal info carefully).
Cancellation during a commitment
Cancel does not mean “stop charging next month.” The customer cancels commitment renewal. Billing continues through remaining periods of the current term.
On cancel mid-commitment:
- Commitment-level auto-renew goes off (
commitmentAutoRenewStatus/ commitmentwillAutoRenewsemantics in renewal info). - Period-level
willAutoRenewcan still show that monthly billing continues for remaining periods. - You get
DID_CHANGE_RENEWAL_STATUSwithAUTO_RENEW_DISABLED. - You continue to get
DID_RENEWfor remaining months. - Access continues through the commitment; after the final period you get
EXPIRED.
If your cancel handler still does “disable access at period end” like classic monthly, you will incorrectly revoke paid-through commitment months. Branch on billingPlanType == MONTHLY first.
Billing issues
On payment failure, Apple retries. Revoke access on DID_FAIL_TO_RENEW, restore on recovery (DID_RENEW with billing recovery semantics). After recovery, re-read commitment expiry from the latest transaction — the schedule can shift.
Important Apple detail: Billing Grace Period does not apply to monthly subscriptions with 12-month commitments. Do not assume grace-period logic from annual/monthly products carries over.
Refunds and consumption requests
Refund requests produce CONSUMPTION_REQUEST on your V2 endpoint. Respond with consumption information and preference as for other subscriptions.
Refund effects differ by which period is refunded:
- Prior period refund: that period’s transaction is revoked; the overall commitment continues; do not treat it as full commitment cancellation.
- Current period refund: the commitment ends immediately; revoke access when the latest transaction shows
revocationDate.
Indie implications: cashflow, psychology, churn
Everything in this section is industry context, not Apple policy.
Cashflow psychology
Classic annual puts most of the year’s revenue in month one. Commitment billing spreads the same annual total across twelve charges. For a solo developer, that changes runway math: marketing spend funded by annual spikes behaves differently when revenue arrives as installments. Model both payback curves before you default the paywall to .monthly.
Conversion vs involuntary churn
The pitch is annual retention with a monthly sticker price. That helps hesitant buyers who bounce at “$99 now.” The cost is operational: Apple must successfully bill twelve times. Industry analyses of App Store subscriptions have long flagged involuntary churn (failed cards, expired payment methods) as a large share of losses. Twelve attempts multiply that surface area compared with one annual charge.
Market exclusions matter
The United States and Singapore are excluded. For many apps, US revenue is a large share of App Store income. Enabling the plan helps non-US storefronts; it does not replace a US annual or monthly strategy. Ship storefront-aware paywalls: if pricingTerms lacks .monthly, fall back cleanly to up-front annual and/or classic monthly SKUs.
Refunds and support load
Progress UI (“4 of 12”) reduces confusion, but support still hears “I cancelled, why am I charged?” Your help center copy must match Apple’s model: cancel stops renewal of the next commitment, not remaining payments in the current one. Link customers to Apple’s subscription management sheet rather than inventing a second cancellation story.
When to use which plan
Practical decision matrix for indie / small-team apps:
- Goal — Prefer
- Maximize cash now, simple accounting — Classic annual up-front
- Maximize trial → paid conversion, accept monthly churn — Classic monthly
- Want annual retention with a lower sticker price outside US/SG — Monthly with 12-month commitment on the annual SKU
- US-heavy revenue mix — Keep strong annual + monthly; treat commitment as optional elsewhere
- Complex tier ladder with frequent downgrades — Be careful — downgrades wait until commitment end
A sensible default for many products: keep annual up-front as the featured plan, offer monthly for exploration, and enable the commitment plan where storefronts allow if your analytics show annual sticker shock without willingness to commit monthly. Do not hide the total commitment price — Apple requires it, and trust requires it.
Implementation checklist
- Confirm Xcode 26.5+ SDK and deployment story for OS 26.4+ customers.
- On a one-year auto-renewable product in App Store Connect, enable monthly-with-commitment pricing per territory.
- Attach offers per billing plan if you use trials differently for up-front vs commitment.
- Update paywall: read
pricingTerms, show monthly + total, purchase with.billingPlanType(.monthly). - Entitlement logic:
Transaction.expirationDate(period), never commitment expiry for access. - Account UI: optional progress from
commitmentInfo; prefer system manage-subscriptions sheet. - Server: handle
DID_RENEW,DID_CHANGE_RENEWAL_STATUS, billing failure/recovery,CONSUMPTION_REQUEST, andEXPIREDwith commitment-aware branches. - Test in StoreKit Testing (Xcode 26.5 Billing Plan picker) before sandbox end-to-end.
- Gate merchandising on storefront availability — especially US and Singapore.
FAQ
What is Apple’s monthly subscription with a 12-month commitment?
It is an auto-renewable subscription that bills monthly while the customer commits to twelve months. Apple documents it as a billing plan on a one-year subscription product, not a separate product type. After twelve payments, the commitment renews unless cancelled before renewal.
Is this available in the United States?
Per Apple’s StoreKit documentation, monthly subscriptions with 12-month commitments deploy worldwide except the United States and Singapore. Customers also need compatible OS versions (26.4+ family) and your app built with the Xcode 26.5 SDK or later.
Does canceling stop the next monthly charge?
No. Canceling stops renewal of the commitment after the current twelve-month term. Remaining monthly charges in the current commitment continue. Apple’s system UI and Server Notifications V2 reflect that distinction; your app should too.
Which StoreKit field controls access — period expiry or commitment expiry?
Use Transaction.expirationDate for the current billing period (plus revocation / upgrade checks). Use commitmentInfo.expirationDate only for progress display. Mixing them up over-grants access.
How do Server Notifications V2 change?
Lifecycle notifications continue (DID_RENEW, renewal-status changes, expiry, consumption requests). Signed transaction and renewal payloads gain billingPlanType and commitmentInfo fields so servers can track installment progress and post-commitment renewal preferences.
Should indies replace annual pricing with commitment billing?
Usually no as a blanket replace. Annual up-front still wins for cashflow simplicity. Commitment billing is a second plan on the same annual SKU for storefronts that support it — useful when monthly sticker psychology blocks annual conversion and you can accept installment risk and non-US/SG availability limits.
Closing
Subscription pricing is product design as much as API work. Apple finally gave developers a first-party way to sell yearly commitment with monthly cashflow — with clear StoreKit hooks and stricter rules around cancel, refund, and grace period. Read the official supporting and lifecycle docs before you rewrite your paywall, and keep your entitlement checks boring: period expiry grants access; commitment info tells the story.
— Muhammad Tayyab, full stack and mobile developer in Lahore, Pakistan.
Contact · GitHub · LinkedIn · X
Research sources
- Apple Developer Documentation: Supporting monthly subscriptions with a 12-month commitment
- Apple Developer Documentation: Managing the life cycle of monthly subscriptions with a 12-month commitment
- WWDC26 Session 210: What’s new in Apple In-App Purchase
- Industry context (labeled in body): Adapty and independent developer posts summarizing April–May 2026 rollout and US/Singapore implications