Direct answer: choose the subscriber job before the discount
A win-back offer is an Apple-configured offer for eligible lapsed subscribers to an auto-renewable subscription. Your team configures the eligibility parameters; Apple applies them and resolves overlapping win-back eligibility. Depending on configuration and operating system, the offer can appear in Manage Subscriptions, in your app, on your App Store product page, in editorial selections or personalized recommendations, or through a redemption link. These are potential or conditional surfaces, not guaranteed placements. Apple’s win-back setup guidance documents those distinctions.
A promotional offer is discounted or free subscription pricing for existing or previously subscribed customers. The developer decides which qualifying customers to target and implements the StoreKit purchase flow, including a signature generated on the server. It can support a lapsed-subscriber return, current-subscriber retention, or a relevant upgrade, but it is not a developer-controlled version of Apple’s win-back distribution system. Apple’s promotional implementation guide describes that responsibility.
Both can reactivate lapsed subscribers. Neither guarantees that they will. The useful comparison is therefore not “which discount converts better?” It is: who qualifies, who decides, where does the customer encounter the offer, and can the purchase and measurement systems support that promise? A team can operate both offer types, but it needs separate eligibility records and a shared inventory policy rather than competing discounts with unclear ownership.
Comparison: which subscriber job fits each offer?
Use this matrix to narrow the implementation decision. The limits are Apple configuration limits, not recommended campaign volume or proof of statistical sufficiency. Platform mechanics come from win-back setup, promotional setup, and StoreKit implementation.
Decision dimension Win-back offer Promotional offer --- --- --- Subscriber state Eligible lapsed subscriber; configured per subscription product Existing or previously subscribed customer; supports developer-selected retention, upgrade, or return jobs Eligibility authority Team configures allowed criteria; Apple evaluates eligibility and overlap App Store supplies the existing/expired subscription prerequisite; developer determines additional targeting criteria Where surfaced Manage Subscriptions; supported in-app sheet; promoted App Store surfaces; redemption URL, subject to requirements Developer-merchandised app experience and StoreKit purchase flow; not the same Apple-managed discovery inventory Trigger and merchandising owner Apple-managed eligible display plus developer decisions about promotion, priority, messaging, and supported in-app handling Developer selects the audience, presentation moment, offer, and purchase request Implementation dependencies Approved subscription, offer configuration, applicable OS and surface support; StoreKit for custom in-app handling App Store Connect offer and key setup, product retrieval, eligibility logic, server signature, StoreKit purchase handling Offer inventory Up to 350 created per subscription; up to five running per storefront per subscription Up to 10 active per subscription Geography Configurable country or region availability and storefront prices Applies across storefronts where the subscription is available; cannot be restricted to specific countries or regions; prices can differ Measurement seam Apple offer identity and platform reporting versus company lifecycle and cohort records Developer targeting/exposure and signed purchase attempt versus Apple transaction and offer reporting Common failure Treating a marketing list as proof of Apple eligibility, or promising an unavailable surface Treating offer creation as complete implementation, or issuing a discount without reliable subscriber-state and signing checks
Both offer families support pay as you go, pay up front, or free configurations in Apple’s setup guidance. Those payment structures are not interchangeable customer promises: the duration, payment schedule, and subsequent subscription terms must be understood before a team compares adoption. Record the actual configured offer rather than labeling every incentive a “trial.”
Decision tree: which route should the team evaluate first?
Start with subscriber state, then the desired surface and eligibility authority. Do not begin with the largest available discount or the simplest console setting.
Is the person a current subscriber, a genuinely lapsed subscriber, or neither? A current subscriber does not fit the win-back job. Evaluate a promotional offer only when a current or previously subscribed customer fits the intended business rule. If the person has no subscription history, stop this comparison and review the appropriate acquisition or introductory-offer path separately.
For a lapsed subscriber, do you need Apple-managed eligible discovery? If Manage Subscriptions or a promoted App Store presence is central to the hypothesis, evaluate win-back configuration and the applicable surface requirements. Do not assume an email campaign creates App Store eligibility.
Do you need a developer-defined segment or app moment? If the hypothesis depends on a particular product behavior, support history, or retention moment beyond the win-back configuration controls, promotional offers may fit better. Confirm the App Store subscription-history prerequisite as well as your own business criteria.
Can engineering complete the purchase path? For promotional offers, a configured discount without server signing and StoreKit integration is not launch-ready. For win-back offers, a configured offer does not establish that every intended OS and in-app presentation path works.
Can analytics distinguish selection, purchase, renewal, and refund effects? If not, repair the measurement seam before calling a discount an experiment. A launch may be operationally possible but unable to answer the commercial question.
A “both” decision needs two explicit hypotheses. For example, one hypothesis might concern Apple-managed eligible discovery among lapsed subscribers; another might concern a developer-selected in-app return moment. Combining the numbers without distinguishing exposure and eligibility would conceal the difference the team is trying to evaluate.
This article does not replace the broader work of testing paywall value, timing, and subscription integrity. Offer-type choice is one input to that work, not a substitute for it.
Eligibility authority map: who decides what?
Apple-controlled eligibility and developer-controlled targeting overlap, but they are not the same authority. Write down both before approving a customer-facing claim.
Win-back: configure the rule, do not invent individual entitlement
Apple’s win-back setup uses minimum paid subscription duration, time since last subscribed, and an optional wait between offers. Minimum paid duration supports documented selections from one to 24 months or three, four, and five years. Time since last subscribed requires a minimum and maximum between one and 24 months. The optional wait between offers runs from two to 24 months. Apple also specifies that customers are eligible for the most recently lapsed subscription product within each group, not automatically every product in that group. Win-back setup.
The team owns the lifecycle hypothesis, configuration, dates, storefronts, and communication plan. Apple applies the eligibility rules. When configured win-back offers overlap, Apple automatically selects and displays one based on price, duration, and other factors such as paid subscription tenure. A marketing priority or CRM tag is therefore not a guarantee that a particular discount will be the one shown.
The practical authority record should distinguish “estimated candidate,” “eligible offer available,” “offer encountered,” and “redemption completed.” These are proposed operating states for your team, not new Apple reporting definitions. Keeping them separate prevents an estimated audience from being treated as an entitled customer list.
Promotional: platform prerequisite plus business selection
Apple’s implementation guide describes two layers. The App Store considers customers with an existing or expired subscription in the app eligible to redeem a promotional offer. The developer determines additional criteria for the specific offer, retrieves product details, and requests the server-generated signature used in the purchase. Promotional implementation.
That does not make eligibility an untrusted client-side checkbox. As an implementation-readiness recommendation, your team should reconcile subscription state and authorize the requested product and offer before signing. Define how stale state, changed renewal intentions, or conflicting segments are handled. A secure signature authenticates the offer flow; it does not make an incoherent lifecycle segment commercially useful.
The developer may control whom to target, but promotional offers still apply across all storefronts where the subscription is available. Different storefront prices do not create a country-restricted promotional offer. Promotional setup. Distinguish communication targeting from actual redemption availability in every launch record.
Which win-back surfaces are actually available?
Check the surface and OS together; “available on Apple” is not a sufficient release requirement. Apple documents automatic Manage Subscriptions display on iOS 14.3, iPadOS 14.3, and macOS 14 or later. The in-app win-back sheet requires iOS 18, iPadOS 18, and macOS 15 or later. Promoted product-page, editorial, and personalized App Store surfaces are documented for iOS 18, iPadOS 18, and macOS 15 or later. Win-back surface requirements.
Promoted App Store visibility requires an approved subscription image and promotion of the offer. Editorial selection is not promised. Apple says promoting a win-back offer replaces In-App Purchase promotions in the same storefront, so promotion also has an inventory opportunity cost. Offers can still appear in Manage Subscriptions and supported in-app sheets without App Store promotion.
A generated redemption URL can support an email or website message, and StoreKit 2 can support in-app merchandising. Apple explicitly tells developers to check customer eligibility before sending a link. Treat link distribution as routing, not as a mechanism that overrides eligibility. QA should include customers who do not qualify, unsupported device versions, and a deleted or unavailable offer—not just the happy-path eligible customer.
Promotional offers have different implementation requirements. The cited setup and implementation pages document redemption on iOS 12.2, macOS 10.14.4, and tvOS 12.2 or later. Those minimums describe the cited flow; engineers must still check the availability of the actual APIs they select. They are not evidence that every current app, platform, or storefront is ready without integration. Promotional implementation requirements.
Implementation workflow: hypothesis to evaluation
Launch readiness is a chain of decisions, not a console screenshot. Assign one accountable owner at each handoff and retain the evidence needed to stop safely.
1. Lifecycle hypothesis and exclusion rules
Product and lifecycle leads should state the subscriber problem in observable terms. Is the objective to invite a lapsed customer back after a meaningful product change, offer a relevant upgrade, or respond to a current subscriber’s changed intention? Separate voluntary lapse from billing trouble and entitlement defects. Specify which states are excluded, why an incentive might address the problem, and what evidence would contradict the hypothesis.
Do not confuse offer eligibility with paid-media audience eligibility. The complementary paid re-engagement audience strategy guide owns consent, audience qualification, and media decisions; this page owns the subscription offer-type decision.
2. Eligibility and inventory approval
Lifecycle, engineering, and finance should agree the product, subscriber-state definition, offer ID, payment structure, price, duration, storefront implications, and renewal economics. For win-back, confirm the subscription is approved before creating the offer. Apple documents scheduling no earlier than the following day and a minimum three-day run; regional start times vary. Win-back configuration.
For promotional offers, confirm the subscription product and key setup, the active-offer inventory, and the fact that availability cannot be limited by country. Assign an owner who can retire obsolete identifiers and reconcile the live inventory with the launch plan. Stop if a proposed segment assumes controls the chosen offer does not provide.
3. StoreKit and server readiness
Engineering should document the selected API path, supported OS range, product retrieval, localized pricing, transaction handling, and entitlement reconciliation. For promotional offers, Apple’s guide requires first determining eligibility, obtaining product details, and generating a signature on the server. The signature is time-sensitive, unique per offer, and redeemable once in the documented flow. StoreKit promotional flow.
Keep private signing keys on the server, not in the app or marketing tools. Define recoverable behavior when signing fails, an offer disappears, or subscription state changes during the flow. This article is an implementation brief, not a complete cryptographic or StoreKit specification; use the current documentation for the chosen integration. No key, endpoint, or live app implementation is created by choosing the offer type.
4. QA and launch authorization
QA should exercise current, lapsed, never-subscribed, ineligible, and conflicting-segment cases using the appropriate testing setup. Check localized price and duration, cancellation, restore or entitlement reconciliation, duplicate attempts, signing failure, and expired or deleted inventory. Test the actual routing path and supported OS, including what customers see when the offer cannot be used.
Apple notes that promotional product metadata changes can take up to an hour to appear in sandbox. Promotional setup. Account for propagation before mistaking an old test response for a new business rule. Stop launch if the purchase promise, returned product, entitlement, and analytical record disagree.
5. Evaluation and stopping conditions
Before launch, define the observation period in relation to the offer and subsequent paid renewal, not an arbitrary universal window. Name the decision owner and the comparison method. Pause distribution if unexpected eligibility, wrong pricing, broken entitlement, refund anomalies, or missing lifecycle events undermine interpretation. Do not continue a discount merely because the redemption count is rising.
Two ledgers: adoption is not downstream contribution
Keep Apple offer reporting and company-side economics separate, then reconcile their definitions. Apple’s Offers dashboard covers introductory, offer-code, promotional, and win-back offers. It includes offer volume, conversion to paid subscriptions, churn, lifecycle adoption and renewals, billing issues and recoveries, and territory or source breakdowns. Apple Offers reporting.
Ledger one: offer adoption and paid conversion
Record offer family and ID, subscription product, dates, storefront, eligibility definition, intended surface, and any company-side exposure or targeting events available under your consent and instrumentation rules. Keep purchase attempts distinct from verified redemptions and later paid conversion. Record denominator definitions and missingness rather than presenting every ratio as the same conversion rate.
Apple Analytics supplies its own definitions and available dimensions. Your CRM or app telemetry may describe communication delivery and presentation, but cannot automatically identify every Apple-managed exposure. Reconcile by compatible offer and product identifiers, periods, and territory; do not force incompatible totals to agree or assume a complete person-level join.
Ledger two: retention and refund-adjusted contribution
Finance and analytics should follow post-offer paid renewals, cancellations, refunds, billing recovery, and the cost of incentives and distribution. Define contribution using approved proceeds, refunds, variable service costs, and relevant channel costs. Keep observed values separate from modeled future value and immature cohorts separate from mature ones.
Use the complementary cohort value and acquisition-ceiling framework for that economic model. An offer dashboard is not a replacement for it. A free period can increase adoption while producing an unresolved paid-renewal question; a paid promotion can produce cash while still failing the retention hypothesis.
Changes in either ledger do not establish causality. Segment composition, product changes, seasonality, billing recovery, and exposure selection may explain differences. Promotional cohorts are developer-selected; Apple-managed eligibility also selects a particular population. Use an appropriate comparison design where feasible, and label descriptive reporting as descriptive when a valid counterfactual is unavailable. Do not infer lower CAC, CPI, CPA, or higher ROAS from a redemption chart.
What can the win-back eligibility report tell you?
Apple’s report provides aggregated churned-subscription counts as of the reporting date and can estimate potential eligibility. It includes paid tenure, time since lapse, previous win-back redemption, time since the last win-back, and territory. Individual rows appear only when the grouping has at least five churned subscriptions. Win-back eligibility report.
It is not a named customer list, a real-time entitlement decision, or a demand forecast. Missing small groups are not proof of zero eligible customers. The five-subscription threshold is a reporting rule, not an experiment sample-size recommendation. Use the report for planning ranges and inventory feasibility, then separately verify customer-level eligibility through the supported product flow.
Governance: overlapping offers and discount inventory
One inventory register should describe every live promise, even when different systems decide eligibility. Include product and group, offer family and ID, owner, subscriber job, payment structure, dates, storefront availability, messaging, supported routing, and retirement plan. Document which fields are immutable or require replacement before promising quick changes.
Apple resolves overlapping win-back offers automatically, but that does not resolve the team’s broader business conflict between promotional, win-back, and other incentives. Win-back overlap handling. Define your own precedence for communications and app merchandising, and do not portray that policy as control over Apple’s ranking or selected offer.
For promotional offers, Apple says only price can be edited after creation; changing duration or type requires a new offer. Promotional editing rules. Preserve identifier history for measurement, and avoid repurposing an offer label to mean a different lifecycle hypothesis. Finance should approve the economic exposure before lifecycle teams distribute a new discount.
Fictional example: one app, two subscriber jobs
The following is fictional, not a Sharply Labs client result. A subscription learning app has shipped a substantial new course sequence. Its team wants to invite genuinely lapsed customers back and separately offer a relevant upgrade to current subscribers using advanced lessons.
The lapsed-customer hypothesis evaluates a win-back offer on the appropriate most recently lapsed product, with documented tenure and lapse criteria. The team checks the eligible surface and supported OS, decides whether App Store promotion merits replacing other promotion inventory, and prepares truthful email routing without promising eligibility to every recipient.
The current-subscriber hypothesis evaluates a promotional offer with developer-defined product behavior and upgrade criteria. Engineering verifies the subscription-history prerequisite, product details, signing, and resulting entitlement. Lifecycle communications exclude people already receiving a conflicting message according to the team’s own policy.
Analytics keeps the two offer IDs and selection mechanisms separate. It evaluates adoption first, then subsequent paid renewals and refund-adjusted contribution. If apparent adoption rises but entitlement failures or missing renewals prevent interpretation, the team stops and repairs the flow. No uplift, revenue result, or winning offer is assumed in this example.
When neither offer is the fix
An incentive cannot diagnose a broken subscription system or establish product value. Billing issues need a billing and recovery investigation; customers should not be treated as voluntarily lapsed simply because a company record is stale. Entitlement defects need engineering repair. Weak recurring value needs a product decision. Bad segmentation needs clearer state definitions, and inadequate event integrity needs instrumentation and reconciliation.
If the unresolved decision is whether subscriptions are the right model at all, use the complementary subscriptions-versus-ads monetization decision. Do not use a temporary discount to conceal that larger uncertainty. Similarly, a failed communication channel does not prove an offer type is unsuitable, and a successful purchase does not prove long-term product satisfaction.
Limitations and a scoped next decision
These sources describe Apple mechanics, not agency results or a universal performance recommendation. Requirements vary by OS, surface, product, storefront, and implementation path. Platform reporting and company telemetry have different definitions and missingness. Recheck current documentation and actual account configuration before launch. No benchmark, search demand, ranking, proprietary methodology, or causal outcome is asserted here.
For subscription-app founders, growth and lifecycle leads, monetization/product owners, iOS engineers, and analytics leads deciding how to re-acquire lapsed users or retain or upgrade current or former subscribers, Sharply Labs can examine subscriber states, offer inventory, StoreKit/app flow, paid and lifecycle channels, and measurement design. The proposed deliverable is a prioritized offer and experiment plan, with readiness gaps, owners, and stopping conditions—not a promise that discounting will work.
Review our mobile app growth service and evidence-first scope, then request an offer-readiness conversation. Our growth services provide the wider paid and lifecycle context. The conversation does not promise reactivation, conversion, retention, LTV, revenue, ROAS, CAC, CPI, or CPA results.
Official sources
All sources accessed October 21, 2026. Citations beside platform claims identify the relevant documentation; none is evidence of a Sharply Labs client outcome.
Apple: Set up win-back offers — eligibility, inventory, configuration, overlap, storefront and surface requirements.
Apple: Set up promotional offers — subscriber scope, inventory, geography, pricing, editing and implementation prerequisites.
Apple: Implementing promotional offers in your app — platform prerequisite, developer selection, product retrieval and server-signed StoreKit flow; cited APIs are not a complete implementation specification.
Apple: Offers analytics — offer families and reporting dimensions, not causal or finance-approved cohort economics.
Apple: Win-back eligibility report — aggregate planning fields and five-subscription row threshold, not individual entitlement.