App Store subscription offer eligibility: who qualifies for introductory and promotional offers

Introductory offers, promotional offers, and offer codes each carry distinct eligibility rules. This post breaks down who qualifies for each, how to check eligibility in StoreKit 2, and how those rules should shape your paywall design.

Apple gives iOS subscription developers three distinct offer mechanisms — introductory offers, promotional offers, and offer codes — and each one has its own eligibility rules governing who can receive it. Get those rules wrong and you'll surface discounts to users who can't redeem them, create confusing paywall experiences, and leave money on the table from users who legitimately qualify for win-back pricing.

This post walks through the eligibility logic for each offer type, explains how to check eligibility at runtime using StoreKit 2, and covers the paywall design implications of each constraint.

The three offer types Apple provides

Before diving into eligibility, it helps to understand what Apple offers developers at a high level:

• Introductory offers come in three variants: a free trial (zero cost for a defined period), pay-as-you-go (reduced recurring price for a set number of billing periods), and pay-up-front (one discounted charge covering the first billing cycle). These are the acquisition offers — designed for first-time subscribers who haven't yet committed to full price.
• Promotional offers are targeted discounts for existing or lapsed subscribers. They look structurally similar to introductory offers (free, discounted price, or pay-up-front), but they require a server-signed request before a purchase can proceed. This signing step is what allows you to gate them to qualifying users.
• Offer codes are alphanumeric codes you distribute outside the App Store — via email, QR code, or influencer partnership — that grant a specific introductory-tier or custom discount when redeemed in your app or directly on the App Store.

The eligibility rules for each type differ in who controls enforcement, how granular the targeting can be, and what developer effort is required. Conflating them is one of the most common implementation mistakes developers make when building subscription paywalls.

Introductory offer eligibility: the one-per-group rule

Apple enforces a single, firm rule for introductory offers: a customer is eligible for an introductory offer only if they have never previously redeemed one for any product in the same subscription group.

This deceptively simple rule has several downstream implications:

• Eligibility is subscription-group scoped, not product scoped. If your “Monthly Premium” and “Annual Premium” products share the same subscription group — as they typically should, to allow in-group upgrades and downgrades — a user who redeemed a trial on the monthly plan cannot claim a trial on the annual plan. They’re in the same group.
• Eligibility is lost permanently after redemption, even if the subscription later lapses. A user who started a 14-day trial two years ago and then cancelled is not eligible for another trial in that group. This is a hard Apple-enforced constraint and cannot be worked around with server-side logic.
• A user who downloaded your app but never subscribed retains eligibility. The trigger is offer redemption, not app download or paywall view. A user who saw your trial CTA, didn’t convert, and returned six months later is still eligible — and your paywall should reflect that.

In StoreKit 2, eligibility checking is a first-class feature. The Product.SubscriptionInfo struct exposes an isEligibleForIntroductoryOffer property — an async computed value you can read before deciding which paywall variant to render. This is far more reliable than the StoreKit 1 approach, which required receipt parsing to infer eligibility and was prone to edge cases around receipt validation timing.

Promotional offer eligibility: current and lapsed subscribers only

Promotional offers are the win-back and retention lever. Unlike introductory offers — which Apple enforces centrally — your app is responsible for determining whether a user qualifies before presenting a promotional offer. Apple’s underlying requirement is that the user must be a current subscriber or have been a subscriber at some point in the past.

In practice, this means:

• Active subscribers qualify — useful for upgrade offers or loyalty discounts to reduce voluntary churn risk.
• Lapsed subscribers qualify — the primary win-back use case. A user who cancelled six months ago and returned to your app after seeing a re-engagement campaign can receive a discounted resubscription offer.
• Never-subscribed users do not qualify. Apple’s system will reject the purchase attempt if you apply a promotional offer to a user with no subscription history in that group.

The eligibility enforcement mechanism is the server-signed offer signature. Your backend must generate a signed request — using your subscription key, a nonce, the user’s App Account Token, the product ID, and the offer ID — before the purchase can be initiated. This design is intentional: it ensures only your server can gate who receives promotional pricing, and it creates an audit trail you can use for analytics and compliance.

Offer types compared

Checking eligibility in code: StoreKit 2 and the server API

Getting the eligibility check right is a prerequisite for showing the correct paywall variant. A production-grade implementation typically involves two checks:

Client-side introductory offer check (StoreKit 2):

1. Load the subscription products using Product.products(for: productIdentifiers).
2. For each product with an attached introductoryOffer, read product.subscription?.isEligibleForIntroductoryOffer.
3. Display the trial CTA and pricing copy only if the result is true. For ineligible users, present the standard subscription price without a trial mention.

Server-side promotional offer check:

1. On app launch (or when the user returns after a lapse), send the user’s App Account Token to your server.
2. Your server queries the App Store Server API — specifically, GET /inApps/v1/subscriptions/{transactionId} — to retrieve the subscription history and confirm past subscriber status.
3. If the user qualifies, your server generates a signed offer using the subscription key and returns it to the app so the promotional purchase can proceed.

For a detailed walkthrough of the App Store Server API authentication and query patterns, see the App Store Server API transaction verification guide. For the full promotional offer signing flow, the iOS subscription promotional offers post covers the key ID, nonce, timestamp, and signature construction step by step.

One common mistake in this flow: skipping the server-side check and relying entirely on the client-side isEligibleForIntroductoryOffer property to decide whether to surface a promotional offer. That property only reflects introductory offer eligibility — it says nothing about whether the user was ever a subscriber, which is what determines promotional offer eligibility.

Paywall design implications

Eligibility rules should drive your paywall variant logic proactively, not serve as error handling after a failed purchase attempt.

Match your CTA text to actual eligibility. Showing “Start free trial” to an ineligible user, then having the transaction fail with a confusing error, is a meaningful conversion killer. StoreKit 2 makes the check cheap — do it before rendering, not after the tap.

Design a distinct win-back variant. Lapsed users returning to your app represent a qualified, high-intent segment — they’ve already decided your product has value once. A paywall that acknowledges their history (“Welcome back — here’s 40% off your first month”) will generally outperform the generic acquisition paywall. Research published by Phiture on mobile re-engagement campaigns consistently highlights offer personalization as one of the highest-leverage variables for return conversion. RevenueCat has also noted in their engineering blog that win-back promotional offers tend to outperform generic price drops for lapsed subscriber segments.

Anchor on value, not price, for users ineligible for any offer. A user who is not eligible for a trial and has seen your subscription paywall multiple times needs a different conversion argument than a first-time visitor. Price anchoring (showing a crossed-out price next to the current price) is less effective here than outcome anchoring — what the user will be able to do, accomplish, or save with the subscription.

Test offer copy separately from offer mechanics. Whether you offer 7 days free or 14 days free changes trial-start rates; whether you say “7-day free trial” or “Try free for a week” also changes them, but independently. Subscription management SDKs like RevenueCat and Adapty provide remote paywall configuration that lets you run these copy experiments without shipping new builds — useful given that App Store review adds latency to any test that requires a code change.

For guidance on structuring offers sequentially across a user’s lifecycle, see the iOS subscription offer sequencing guide. And if you’re working through how to configure and manage offer pricing across markets, the AppsOps pricing tools provide territory-by-territory visibility into what each tier costs in local currency.

Sources and further reading

• Apple: App Store subscriptions overview — introductory offers, promotional offers, and offer codes
• Apple Developer Documentation: StoreKit reference
• Apple Developer Documentation: App Store Server API reference
• RevenueCat Blog — subscription implementation guides and conversion data
• Adapty Blog — iOS paywall design and subscription analytics
• Phiture Mobile Growth Stack — re-engagement research and ASO findings