4.14.1

[yusuftor]

Changes in this pull request

Enhancements

• Localizes all alerts into 41 languages.
• Makes sure to refresh free trial eligibility on every paywall open.

Fixes

• Makes device.isSandbox more reliable.
• Fixes the web restore alert not showing the "Yes" action button and "Cancel" incorrectly triggering the restore action.
• Fixes a rare issue where a user's subscription could remain active after a refund, preventing paywalls from being shown.
• Fixes trial eligibility for Stripe paywalls and tracks freeTrial_start.
• Fixes an issue where transaction_complete could be missing transaction information when a crossgrade occurred while using a purchase controller.
• Fixes terminated webviews refreshing in a loop on low RAM devices.

Checklist

• All unit tests pass.
• All UI tests pass.
• Demo project builds and runs on iOS.
• Demo project builds and runs on Mac Catalyst.
• Demo project builds and runs on visionOS.
• I added/updated tests or detailed why my change isn't tested.
• I added an entry to the CHANGELOG.md for any breaking changes, enhancements, or bug fixes.
• I have run swiftlint in the main directory and fixed any issues.
• I have updated the SDK documentation as well as the online docs.
• I have reviewed the contributing guide

Greptile Summary

This PR (4.14.1) delivers a broad set of fixes and enhancements: localization of all SDK alerts into 41 languages, more reliable sandbox detection via AppTransaction, a refund-deactivation fix through two cooperating changes in EntitlementProcessor and SK2ReceiptManager, Stripe trial eligibility support, a fix for the web-restore alert's action wiring, and a behavioral improvement that refreshes free-trial eligibility on every paywall open rather than only at first fetch.

Key changes:

• Free trial refresh on every open — PaywallRequestManager.updatePaywall is now async and calls refreshFreeTrialAvailability, which re-evaluates both App Store and Stripe trial eligibility against the user's current entitlement state each time a paywall is requested.
• Stripe trial eligibility — New checkStripeTrialEligibility / hasEverHadEntitlement methods determine whether a Stripe product with trialDays > 0 should show a trial offer, using customerInfo.entitlements to detect prior subscriptions without StoreKit.
• Refund fix — EntitlementProcessor now overrides isActive to false when subscription state is .revoked/.expired, and SK2ReceiptManager propagates this correction to the purchases set, preventing a refunded subscription from remaining "active."
• Web-restore alert fix — Adding the explicit action: label to presentAlert corrects the trailing-closure binding that caused "Cancel" to trigger the restore action instead of "Yes."
• FreeTrialStart event for web redemptions — The event and trial notifications are now correctly gated on both trialPeriodDays > 0 and paywallInfo.isFreeTrialAvailable.
• Price calculation accuracy — SubscriptionPeriod, SK2StoreProduct, StripeProductType, and StoreProductDiscount all updated to use 365/52 and 365/12 for week/month conversions, and a shared Decimal.roundedPrice() extension replaces the per-type private helpers.

Confidence Score: 4/5

• Safe to merge — fixes are well-targeted and tested; the only concern is a changed equality contract on StripeProduct that could cause unexpected cache misses if trial configuration changes server-side.
• The changes are backed by solid new tests (365+ lines in WebEntitlementRedeemerTests, 467 lines in StripeTrialEligibilityTests). The refund-fix logic in EntitlementProcessor + SK2ReceiptManager is consistent and addresses a real data-correctness issue. The web-restore alert bug fix is straightforward. The one point of concern worth watching is that StripeProduct.isEqual/hash now include trialDays, which changes object equality semantics and could cause unexpected cache behavior if the server changes trial configuration without changing the product ID.
• Sources/SuperwallKit/Models/Product/StripeProduct.swift (changed equality semantics) and Sources/SuperwallKit/Paywall/Request/Operators/AddPaywallProducts.swift (core free-trial refresh logic called on every paywall open).

Important Files Changed

Filename	Overview
Sources/SuperwallKit/Paywall/Request/Operators/AddPaywallProducts.swift	Major refactor: free trial eligibility computation moved out of getVariablesAndFreeTrial into a new refreshFreeTrialAvailability method called on every paywall open (cached or not). Adds Stripe trial eligibility check (checkStripeTrialEligibility) and extracts App Store check into checkAppStoreTrialEligibility. Logic is correct but the product loop could be expressed more clearly.
Sources/SuperwallKit/Paywall/Request/PaywallRequestManager.swift	updatePaywall made async; now calls refreshFreeTrialAvailability on every paywall retrieval (cache hit, active task, or fresh fetch), ensuring trial eligibility always reflects current subscription state.
Sources/SuperwallKit/StoreKit/Products/Receipt Manager/Receipt Manager/SK2ReceiptManager.swift	Adds a post-processing pass over purchases that corrects isActive to false when all entitlements for that product are revoked/expired — fixes the refund-doesn't-deactivate-subscription bug. Works in tandem with the EntitlementProcessor fix.
Sources/SuperwallKit/StoreKit/Products/Receipt Manager/EntitlementProcessor.swift	Adds authoritative resolvedIsActive override: forces entitlement isActive = false when subscription state is .revoked or .expired, preventing a revoked subscription from appearing active due to stale transaction data.
Sources/SuperwallKit/Web/WebEntitlementRedeemer.swift	Two fixes: (1) FreeTrialStart event now fired on Stripe web redemptions when isFreeTrialAvailable is true; (2) trial notification scheduling is now correctly gated on both trialPeriodDays > 0 and isFreeTrialAvailable. Also fixes TransactionAbandon passing a non-nil product.
Sources/SuperwallKit/Paywall/View Controller/Web View/SWWebView.swift	Process-termination retry logic now gated on delegate.isActive: retries up to 3× while the paywall is visible, then calls delegate.webViewDidFail() so the user sees an error. Inactive/deallocated delegate path silently marks didFailToLoad. Count reset moved to loadURL.
Sources/SuperwallKit/StoreKit/Transactions/TransactionManager.swift	All hard-coded English alert strings replaced with LocalizationLogic.localizedBundle() lookups. Critical fix: web-restore alert now uses explicit action: label, preventing the trailing closure from silently binding to the wrong parameter and causing "Cancel" to trigger the restore action.
Sources/SuperwallKit/Models/Product/StripeProduct.swift	Adds trialDays: Int? field with proper encode/decode and Equatable/Hashable support. isEqual/hash now include trialDays, changing equality semantics — two products with the same id but different trialDays are now distinct objects, which may affect cache keying.
Sources/SuperwallKit/StoreKit/Products/StoreProduct/SubscriptionPeriod.swift	Price-per-period calculations updated to use astronomically accurate averages (365/52 days/week, 365/12 days/month) instead of simplified integers. Decimal.roundedPrice() extension extracted here to eliminate duplication across SK2StoreProduct, StripeProductType, and TestStoreProduct.
Sources/SuperwallKit/Misc/Extensions/Transaction/Transaction+LatestSince.swift	New currentEntitlement(for:since:) helper used by PurchasingCoordinator to find transactions near the purchase date. Uses currentEntitlements(for:) (iOS 18.4+) or falls back to the deprecated currentEntitlement(for:). Fallback will produce a deprecation warning on Swift 6.1+ toolchains.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[PaywallRequestManager.getPaywall] --> B{Cached paywall?}
    B -- Yes --> C[updatePaywall async]
    B -- No --> D[getProducts - fetch + build productVariables]
    D --> C
    C --> E[refreshFreeTrialAvailability]
    E --> F{Test mode override?}
    F -- forceAvailable/Unavailable --> G[Return early with override]
    F -- useDefault --> H{Developer isFreeTrial override?}
    H -- Set --> G
    H -- nil --> I[Load storeKitManager.productsById]
    I --> J[Loop App Store products]
    J --> K{Product in productsById?}
    K -- No --> J
    K -- Yes --> L[checkAppStoreTrialEligibility]
    L --> M{eligible?}
    M -- true --> N[isFreeTrialAvailable = true, break]
    M -- false --> J
    N --> O[paywall.isFreeTrialAvailable = true]
    J -- exhausted --> P[paywall.isFreeTrialAvailable = false]
    P --> Q{isFreeTrialAvailable still false?}
    Q -- Yes --> R[checkStripeTrialEligibility]
    R --> S{introOfferEligibility == .ineligible?}
    S -- Yes --> T[return false]
    S -- No --> U[Loop Stripe products with trialDays > 0]
    U --> V[hasEverHadEntitlement via customerInfo]
    V --> W{Has entitlement?}
    W -- No --> X[return true - trial available]
    W -- Yes --> U
    U -- exhausted --> T
    X --> Y[paywall.isFreeTrialAvailable = true]
    Q -- No --> O
    O --> Z[Return updated paywall]
    Y --> Z
    T --> Z

Loading

Comments Outside Diff (1)

1. Sources/SuperwallKit/Misc/Extensions/Transaction/Transaction+LatestSince.swift, line 76-88 (link)

   unsafePayloadValue used for best-transaction selection

   The loop on iOS 18.4+ uses result.unsafePayloadValue to read the purchase date for comparison purposes before the cryptographic signature has been verified. While the full VerificationResult is ultimately returned (so callers can verify it), the selection of which result to surface can be influenced by a tampered transaction whose purchaseDate has been crafted to appear newer.

   Consider guarding against unverified results when choosing the best transaction:

   for await result in Transaction.currentEntitlements(for: productId) {
     // Skip unverified results when selecting the best candidate
     guard case .verified(let transaction) = result else { continue }
     if !transaction.purchaseDate.isWithinAnHourBefore(purchaseDate) { continue }
     if let currentBest = best?.unsafePayloadValue,
       currentBest.purchaseDate >= transaction.purchaseDate { continue }
     best = result
   }

   This is a pattern already used safely in the fallback path for pre-iOS 18.4, but the new multi-result path skips verification entirely during selection.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: Sources/SuperwallKit/Misc/Extensions/Transaction/Transaction+LatestSince.swift
   Line: 76-88
   
   Comment:
   **`unsafePayloadValue` used for best-transaction selection**
   
   The loop on iOS 18.4+ uses `result.unsafePayloadValue` to read the purchase date for comparison purposes before the cryptographic signature has been verified. While the full `VerificationResult` is ultimately returned (so callers can verify it), the *selection* of which result to surface can be influenced by a tampered transaction whose `purchaseDate` has been crafted to appear newer.
   
   Consider guarding against unverified results when choosing the best transaction:
   
   ```swift
   for await result in Transaction.currentEntitlements(for: productId) {
     // Skip unverified results when selecting the best candidate
     guard case .verified(let transaction) = result else { continue }
     if !transaction.purchaseDate.isWithinAnHourBefore(purchaseDate) { continue }
     if let currentBest = best?.unsafePayloadValue,
       currentBest.purchaseDate >= transaction.purchaseDate { continue }
     best = result
   }
   ```
   
   This is a pattern already used safely in the fallback path for pre-iOS 18.4, but the new multi-result path skips verification entirely during selection.
   
   How can I resolve this? If you propose a fix, please make it concise.

2. Sources/SuperwallKit/StoreKit/Products/Receipt Manager/Receipt Manager/SK2ReceiptManager.swift, line 2241-2253 ([link](https://github.com/superwall/superwall-ios/blob/68bfaa710552bed189cafbb2668997843047402a/Sources/SuperwallKit/StoreKit/Products/Receipt Manager/Receipt Manager/SK2ReceiptManager.swift#L2241-L2253))

   Refund correction only runs when entitlements are non-empty

   The guard !productEntitlements.isEmpty is intentional to avoid falsely flagging products with no mapped entitlements, which is documented. However, a comment explaining this edge case would help future readers understand why a product with zero entitlements is exempt from the correction and keeps its original isActive state even after a refund.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: Sources/SuperwallKit/StoreKit/Products/Receipt Manager/Receipt Manager/SK2ReceiptManager.swift
   Line: 2241-2253
   
   Comment:
   **Refund correction only runs when entitlements are non-empty**
   
   The guard `!productEntitlements.isEmpty` is intentional to avoid falsely flagging products with no mapped entitlements, which is documented. However, a comment explaining this edge case would help future readers understand why a product with zero entitlements is exempt from the correction and keeps its original `isActive` state even after a refund.
   
   How can I resolve this? If you propose a fix, please make it concise.

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

3. Sources/SuperwallKit/Paywall/Request/PaywallRequestManager.swift, line 107-122 (link)

   updatePaywall is called on the cached task's value before the task is removed

   When a cached paywall is returned from activeTasks, the sequence is:

   1. existingTask.value is awaited (suspends the actor).
   2. updatePaywall (now async) is called — suspends again.
   3. The task is never removed from activeTasks inside this path.

   Looking at the broader context, the task is removed from activeTasks inside the new-task creation path (where the task itself calls activeTasks[requestHash] = nil). For the existingTask path the task entry stays alive until a subsequent request hits the new-task branch. This is a pre-existing issue but is now more visible because updatePaywall became async and introduces an additional suspension point where a second concurrent caller could reach the existingTask branch and share the same task reference even after the first caller has already consumed the result.

   This is likely fine in practice because updatePaywall doesn't mutate the cached task, but it may be worth adding activeTasks[requestHash] = nil at the end of the existingTask path to keep the lifecycle symmetric with the new-task path.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: Sources/SuperwallKit/Paywall/Request/PaywallRequestManager.swift
   Line: 107-122
   
   Comment:
   **`updatePaywall` is called on the cached task's value before the task is removed**
   
   When a cached paywall is returned from `activeTasks`, the sequence is:
   
   1. `existingTask.value` is awaited (suspends the actor).
   2. `updatePaywall` (now async) is called — suspends again.
   3. The task is never removed from `activeTasks` inside this path.
   
   Looking at the broader context, the task is removed from `activeTasks` inside the new-task creation path (where the task itself calls `activeTasks[requestHash] = nil`). For the `existingTask` path the task entry stays alive until a subsequent request hits the new-task branch. This is a pre-existing issue but is now more visible because `updatePaywall` became async and introduces an additional suspension point where a second concurrent caller could reach the `existingTask` branch and share the same task reference even after the first caller has already consumed the result.
   
   This is likely fine in practice because `updatePaywall` doesn't mutate the cached task, but it may be worth adding `activeTasks[requestHash] = nil` at the end of the `existingTask` path to keep the lifecycle symmetric with the new-task path.
   
   How can I resolve this? If you propose a fix, please make it concise.

_{Last reviewed commit: c314cb9}

Greptile also left 4 inline comments on this PR.