Implementing iOS Subscriptions: StoreKit 2, Grace Period, and Promotional Offers

Auto-renewable subscriptions are the most complex type of in-app purchase. Not because StoreKit is inherently complicated, but because of the entire ecosystem that surrounds it: grace periods, billing retry, downgrade/upgrade between tiers, promo offers, introductory pricing, and finally — handling churn through expirationIntent. An error at any stage leads to revenue loss. We implement subscriptions turnkey in 3–5 days, ensuring correct logic at every stage of the lifecycle.

The Subscription Lifecycle and Where It Breaks

An iOS subscription isn't just active or not. Apple automatically renews it 24 hours before expiration. If payment fails, a billing retry period begins (up to 60 days). During this time, the subscription status is expired, but Apple continues retrying. Most apps block access right after expirationDate — that's wrong.

The correct logic: check renewalInfo.isInBillingRetryPeriod. If true, grant a grace period (configured in App Store Connect, typically 6 days for annual, 3 days for monthly). A user with a card issue should not lose access immediately.

StoreKit 2 handles grace period transparently, reducing churn by 20–30% compared to manual implementation with StoreKit 1. Here's an example of correct validation:

for await result in Transaction.currentEntitlements {
    guard case .verified(let transaction) = result else { continue }

    if transaction.productType == .autoRenewable {
        let renewalInfo = try? await transaction.subscriptionStatus.first?.renewalInfo
        let isInGracePeriod = renewalInfo?.gracePeriodExpirationDate != nil
        let isRetrying = renewalInfo?.isInBillingRetryPeriod == true

        if transaction.revocationDate == nil &&
           (transaction.expirationDate ?? .distantPast > .now || isInGracePeriod || isRetrying) {
            unlockPremium()
        }
    }
}

Why Grace Period Matters

Without a grace period, users with payment issues lose access instantly. Apple allows up to 16 days of grace — enough time for the customer to update their card and for you to retain them. Our experience shows that 70% of users return to payment within the grace period. If you block access immediately, they leave permanently.

Tiers and Transitions Between Them

If your app has multiple tiers (Basic, Pro, Enterprise), you need a subscription group in App Store Connect. All tiers belong to one group; a user can have only one active subscription in a group at a time.

Upgrade (to a higher tier) takes effect immediately; Apple recalculates the remaining balance. Downgrade (to a lower tier) takes effect at the next billing period. Crossgrade (same price, different tier) depends on configuration: immediate or deferred.

Track transitions on the client via originalTransactionID and subscriptionGroupID. On the server, store full transaction history and handle Apple Server Notifications v2 (App Store Server Notifications). Critical event types: DID_RENEW, DID_FAIL_TO_RENEW, EXPIRED, GRACE_PERIOD_EXPIRED, REFUND.

How to Handle Tier Transitions?

Upgrades activate immediately — Apple prorates the cost. Downgrades are deferred until the next cycle. Crossgrades can be immediate or deferred as set in App Store Connect. Update the UI accordingly, showing the effective date of the change. Use renewalInfo.renewalDate and offerType.

Introductory and Promotional Offers

Introductory pricing (first N periods at a reduced price) is configured in App Store Connect and automatically applied to new subscribers. Problem: a user who cancelled and wants to return does not get the intro price again. For that, promotional offers exist — you can grant them based on your logic (win-back campaigns).

The signature for a promotional offer is generated on the server with the private key from App Store Connect:

// On the client, create paymentDiscount
let discount = SKPaymentDiscount(
    identifier: "winback_3months",
    keyIdentifier: keyID,
    nonce: nonce,        // UUID from server
    signature: signature, // signature from server
    timestamp: timestamp
)
payment.paymentDiscount = discount

Without a server-generated signature, the promotional offer is invalid — Apple validates the signature server-side.

What's Included in the Work

• Audit of current IAP implementation and subscription groups
• Design of tier and group schemas (subscription groups) aligned with business logic
• Integration of StoreKit 2 with support for grace period, billing retry, and error handling
• Configuration of App Store Server Notifications (v2) on the backend with critical event processing
• Implementation of win-back logic using promotional offers
• Code documentation and churn analytics integration
• Team training on Sandbox and subscription testing
• Post-launch support (1 month free)

Our Work Process

Current implementation audit → design subscription group and tier structure → integrate StoreKit 2 with grace period and billing retry → configure App Store Server Notifications on the backend → implement win-back and promo offer logic → test in Sandbox with simulated expiration (Sandbox compresses time: 1 month = 5 minutes).

Timeline: 3–5 days depending on number of tiers, backend presence, and churn analytics requirements. Cost is determined individually after analyzing your project. Contact us for a consultation — we'll assess scope and propose the best solution. Get advice from a certified iOS developer with 5+ years of subscription implementation experience.

We guarantee: correct handling of billing retry, grace period, and all transition types, compliance with App Store Review Guidelines (Sections 4.2 and 5.1), and full support during testing and release.

Mobile App Monetization: IAP, Subscriptions, and Ad Mediation

An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.

Why StoreKit 2 is the Best Choice for IAP?

StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.

But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.

A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.

How Not to Lose Revenue on Subscriptions?

The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.

Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.

Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).

Ad Mediation: Boosting CPM via Bidding

Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.

ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.

Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.

How to Design a Freemium Model and Paywall?

Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.

A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.

Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).

Scope of Monetization Work

• Current model audit — analysis of funnel, paywall, price tiers.
• IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
• Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
• Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
• Documentation — description of entitlements, restoration procedure, review checklist.
• Team training — analysis of typical mistakes, support recommendations.
• Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.

Estimated Timelines

Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.