iOS subscription promotional offers: win-back mechanics, eligibility rules, and conversion strategy

Apple's promotional offer system is one of the most powerful and underused retention tools for iOS subscription apps. This guide covers eligibility rules, the three discount structures, the server-side signature requirement, and how to wire promotional offers into win-back and loyalty campaigns.

Most iOS subscription developers discover promotional offers by accident — usually when a churned user asks for a discount and the developer realises they have no mechanism to give one. That's a shame, because Apple's promotional offer system is one of the most powerful (and underused) retention tools in the ecosystem.

This guide covers everything you need to use promotional offers deliberately: how they differ from introductory offers, the three discount structures, eligibility mechanics, the cryptographic signature requirement, and how operators use them for win-back and loyalty campaigns.

Promotional offers vs. introductory offers: the critical distinction

Apple has two separate offer systems for subscriptions, and they are not interchangeable.

Introductory offers (covered in depth in iOS subscription introductory offers: types, limits, and best practices) apply only to users who have never held an active or lapsed subscription in the same subscription group. Once a user has ever been a subscriber — even if they cancelled years ago — they are permanently ineligible for introductory offers in that group.

Promotional offers were introduced precisely to fill that gap. They are available to:

• Current active subscribers (loyalty or upgrade incentives)
• Previously subscribed users who have since cancelled (win-back)
• Users whose subscription lapsed due to a billing failure (involuntary churn recovery)

This single eligibility difference makes promotional offers the correct tool for re-engagement. If your win-back emails link to a paywall that only shows introductory pricing, you are almost certainly showing eligible users the full price — and wondering why conversion is poor.

The three discount structures

Promotional offers share the same three discount types as introductory offers, but they behave differently in context.

A few implementation details worth knowing up front:

• You can configure up to 10 promotional offers per in-app purchase product in App Store Connect. Each offer gets its own identifier string you reference in code.
• Offers are per-product, not per-subscription group. An annual subscription and a monthly subscription in the same group each need their own offer configurations.
• Apple does not impose a lifetime "one per customer" cap the way it does for introductory offers. The same user can redeem multiple promotional offers over their lifetime, though RevenueCat and similar SDKs let you enforce your own business rules on top.

Eligibility: how Apple determines who qualifies

Apple enforces eligibility server-side. When a user attempts to redeem a promotional offer, the App Store checks their purchase history for the subscription group. The offer will silently fail — or the transaction will fail — if the user has never held an active subscription in the group.

"Previously active" means the user completed at least one paid or introductory-offer billing period. A user who started a free trial and cancelled before it converted does not qualify for promotional offers. This is a subtle but important distinction when building win-back logic: segment your lapsed users by whether they actually converted to paid before constructing promotional offer campaigns.

This also means your pricing strategy and segmentation work should align: understanding who is a "lapsed paid" vs. "lapsed trial" subscriber is a prerequisite for running promotions efficiently.

The signature requirement: why this shapes your implementation

Unlike introductory offers — which any eligible user can redeem from a standard StoreKit paywall — promotional offers require a server-generated cryptographic signature for each redemption attempt. This is a deliberate gate: Apple requires you to demonstrate, from your own server, that you are intentionally offering the discount to a specific user.

The signature is an ECDSA-P256 signature computed from a concatenation of:

• Your app's bundle ID
• The product identifier
• The offer identifier
• An application username (your internal user ID)
• A nonce (UUID, generated server-side per request)
• A timestamp (Unix time in milliseconds)

The private key is a .p8 file you generate in App Store Connect — the same key format used for App Store Connect API authentication (see Setting up the App Store Connect API key: a 5-minute guide for key generation steps). The public half is uploaded to Apple; you hold the private half on your server.

This signing flow means promotional offers cannot be implemented client-side only. You need a backend endpoint that:

1. Validates that the requesting user is eligible (check your own subscription records)
2. Generates the nonce and timestamp
3. Computes and returns the signature
4. Passes the signature payload to StoreKit 2's Product.SubscriptionOffer struct (or, for StoreKit 1, SKPaymentDiscount)

RevenueCat handles this signature generation automatically if you configure offers through their dashboard. If you are working closer to the StoreKit metal, Apple's developer documentation covers the signing algorithm in full.

Win-back campaigns: the operational playbook

Promotional offers become genuinely valuable when wired into a communication strategy. A discount sitting idle in App Store Connect does not re-engage users on its own. You have to get the offer in front of the right user at the right moment.

The win-back window matters. Analysis from RevenueCat and Paddle has found that re-engagement probability decays sharply with time since cancellation. Users who churned in the past 30 days convert at meaningfully higher rates than those who lapsed six or more months ago. A "recently cancelled" segment should receive the lowest-friction offer (typically a free period) as quickly as possible, before the user has settled into a competitor or simply forgotten your app exists.

Email with a deep link is the most common pattern. A win-back email contains a deep link that opens your app directly to a paywall pre-loaded with the promotional offer. When the user taps Subscribe, your app requests the signature from your server, StoreKit presents the offer, and Apple processes the discounted transaction. Done well, the entire flow takes under 30 seconds from email tap to subscription reactivation.

Push notifications for users who still have the app. If a user has not deleted your app, push notifications can surface win-back offers in context — particularly effective immediately after a billing failure, where you have a narrow window before the user churns involuntarily. The involuntary churn dynamics, especially in price-sensitive markets, are explored further in Why iOS subscription churn is higher in low-PPP markets.

Graduated offer logic. Some operators run a cascade: a churned user is first offered a free month; if they do not convert within 14 days, the sequence shifts to a discounted pay-as-you-go offer; if they still do not convert, a more aggressive pay-upfront annual deal closes the sequence. This ladder logic lives in your backend — App Store Connect remains offer-agnostic and simply holds the offer configurations you reference by ID.

Retention offers: reaching users before they cancel

Promotional offers are not exclusively for win-back. Many subscription apps deploy them proactively to subscribers who show cancellation signals — visiting the subscription management page repeatedly, reducing usage frequency, or submitting support tickets mentioning pricing.

Apple does not expose a native "user is about to cancel" event (unlike Google Play's cancellation survey). The signals have to be inferred from your own analytics:

• Users who visit settings or account pages more than once in a seven-day window
• Users who open the app but do not engage with core features
• Users who contact support mentioning price or value

A loyalty offer — even something modest like one month at 50% off — presented when a subscriber is considering cancellation has shown meaningful retention impact in case studies published by RevenueCat and Braze. The economics are straightforward: a discounted month is almost always better than losing the subscription entirely and paying acquisition cost to replace the subscriber.

Localization and regional pricing implications

Promotional offers inherit the currency and pricing tier of the parent product, adjusted downward by the offer discount. You do not set a separate promotional price in a foreign currency; the discount percentage or free period applies to whatever the subscriber's local price is.

This matters for PPP-adjusted pricing (detailed in Apple price tier system explained and on the territories reference page): if you have set a lower base price for Brazilian or Indian subscribers using Apple's regional price tiers, the promotional offer discount applies proportionally on top of that lower local price. A 50% discount for an Indian subscriber means 50% of the local INR price, not 50% of the USD price. That is correct behavior — but worth modelling explicitly before estimating the revenue impact of a win-back campaign across a global user base.

In markets where involuntary churn from failed card declines is elevated — typically emerging economies with lower credit card penetration — a promotional free-period offer sent immediately after a billing retry failure can recover subscriptions that would otherwise lapse permanently.

Implementation checklist

Before launching a promotional offer campaign:

1. Confirm your key is configured — .p8 key generated in App Store Connect, private key stored securely on your server and never in client-side code.
2. Build the signature endpoint — test it in the Sandbox environment thoroughly before touching production.
3. Segment your lapsed users — separate "paid then cancelled" from "trial-only cancelled"; only the former qualifies for promotional offers.
4. Define the offer logic — which offer ID, for which user segment, triggered by which event or communication channel.
5. Test the deep-link flow end-to-end — from email tap to completed transaction on a test account before sending to real users.
6. Instrument the conversion funnel — offer presented, offer accepted, first renewal, second renewal. If you only track acceptance, you cannot tell whether discounted subscribers are retaining at a healthy rate long-term.

Sources and further reading

• Apple Developer Documentation: Implementing Promotional Offers in Your App
• Apple Developer Documentation: Generating a Signature for Promotional Offers
• App Store Connect Help: Set Up Promotional Offers
• RevenueCat: iOS Subscription Offers Guide
• RevenueCat: Win Back Churned Subscribers
• Phiture Mobile Growth Stack: Subscription Retention Strategies