Customer Center

[DreamingInBinary]

Changes in this pull request

Adds the Customer Center: a native, self-service subscription-management screen inside the SDK. One call presents it:

Superwall.shared.presentCustomerCenter()

It shows the customer's subscriptions and purchases and lets them restore purchases, open Apple's manage-subscriptions sheet, request a refund, change plans, contact support, answer an exit survey, and browse purchase history. There's a SwiftUI view (CustomerCenterView), a UIKit view controller (CustomerCenterViewController), an Objective-C surface, a delegate, five SwiftUI callback modifiers, five new analytics events, and strings for all 41 locales.

Everything is configured in code via SuperwallOptions.customerCenter. The configuration model is Codable and deliberately shaped so a future dashboard/backend can serve the same JSON without changing the public API — resolution order is per-call argument → options → .default.

Zero-config gives a working screen: with an active App Store subscription you get the subscription card, Restore, Change plan, Request a refund, Cancel subscription (with a cancellation survey), See all purchases, and Account details. The only row that needs configuration is Contact support, which is hidden unless a support email is set.

Requires iOS 15+. The SDK's deployment target is unchanged at iOS 13 — the Customer Center symbols are @available(iOS 15.0, *), because every StoreKit API it drives is iOS 15+ anyway.

Reviewing this

108 files is a lot, but five files are the whole feature — the rest is SwiftUI, tests, and localization:

1. CustomerCenter/Models/CustomerCenterConfiguration.swift — the entire public surface. Start here.
2. Superwall+CustomerCenter.swift — the entry point (~100 lines).
3. CustomerCenter/ViewModel/CustomerCenterViewModel.swift — state, flows, event emission.
4. CustomerCenter/Logic/CustomerCenterPathResolver.swift — which actions appear when. This is the product logic.
5. CustomerCenter/Logic/PurchasePresentationBuilder.swift — badges, status lines, renewal dedupe.

For 4 and 5, the table-driven tests read like a spec and are the fastest way in. Alternatively the commits are in dependency order, tests first, one concept each: git log --reverse --patch <base>..HEAD -- Sources/SuperwallKit/CustomerCenter.

Changes outside CustomerCenter/ are all small, necessary hooks: SuperwallOptions (+2 lines), LogScope (+1 case), DeviceHelper (+1 internal accessor), DependencyContainer (lazy @MainActor manager), the three analytics files (5 new event cases, purely additive), SuperwallKit.md, and one defaulted parameter on a shared test fixture. TransactionManager gains a presentsFailureAlert flag defaulting to true, so paywall restore behaviour is bit-identical.

Deliberately out of scope

Promotional / win-back retention offers (they need server-side signature generation), remote dashboard configuration, support tickets, virtual currencies, and the Android / Flutter / React Native bridges.

Decisions worth a second opinion

• Version stayed at 4.16.4. develop was already ahead of master (4.16.3), so per CLAUDE.md the CHANGELOG entries went into the existing staged section rather than bumping again. New public API arguably warrants 4.17.0 — reviewer's call; it's a three-file change.
• "Customer Center" is also RevenueCat's product name, chosen for discoverability and migration parity. Verified there are no symbol clashes: our Objective-C classes are SWK-prefixed against their RC-prefixed ones, so no duplicate class registration. One real collision was found and fixed — both SDKs put presentCustomerCenter on SwiftUI's View with everything after isPresented defaulted, and Swift silently resolved the bare call to ours (its solver penalises each defaulted argument it fills; ours fills 2, theirs 13), which would have hijacked an existing RevenueCat customer's screen with no error. Our modifier is now presentSuperwallCustomerCenter. Verified by building a target that imports SuperwallKit, RevenueCat and RevenueCatUI together and demangling the linked symbols.
• Refund stays available on expired subscriptions. Apple permits it, but it's a product call.
• "Cancel subscription", not "Manage subscription". In the default configuration that row carries the cancellation survey and opens Apple's cancel sheet, so the old label overstated it. Each locale uses its subscription-termination verb (German kündigen, French résilier, Japanese 解約) rather than the dialog-dismiss word.
• The 41 locale translations are first-draft with no native-speaker review. Worth routing through localization before release.

Known gaps

• The internal navigation flag was replaced with a visibility count, which closed the embedded-mode dismissal hole. Row ordering is nondeterministic when two products tie on both active-ness and expiry date (contents are deterministic). Support/Appearance/ColorPair override isEqual without hash, matching existing convention in CustomerInfo and friends.
• dismiss(completion:)'s UIKit-driven completion path and the SDK's alert-suppression have no automated coverage: the hostless test target cannot complete modal presentations or present a UIAlertController, so such assertions would pass whether or not the code works. Both were verified manually instead.

Testing

1006 tests across 110 suites, all passing. Every task was reviewed by someone other than its author, with a cross-cutting review over the whole branch.

A full manual pass was also run on device across 20 scenarios — purchase, cancel, refund, expiry, billing retry, empty state, restore, delegate callbacks, code-driven configuration — and it found two real bugs that static review did not:

• Apple's manage-subscriptions sheet never appeared after the cancellation survey. ManageSubscriptionsSheet branched on groupId, which turned non-nil in the same update that flipped isPresented true; SwiftUI tore down the modifier that was about to present. Now branches only on #available.
• Restoring with no purchases showed two stacked alerts — the SDK's paywall-worded failure alert on top of the Customer Center's own.

Also fixed from that pass: disclosure chevrons were removed from action rows (a chevron promises a push, and none of those rows push), and the update banner now animates out instead of blinking.

Checklist

• All unit tests pass. (1006 tests / 110 suites)
• All UI tests pass. — N/A, this repo has no UI test target.
• Demo project builds and runs on iOS. (Basic and Advanced; manually exercised on iPhone 17 simulator)
• Demo project builds and runs on Mac Catalyst. (framework builds for Catalyst; the Customer Center is #if os(iOS) and available on Catalyst 15+)
• Demo project builds and runs on visionOS. — not verified; CI doesn't build visionOS.
• I added/updated tests or detailed why my change isn't tested. (See "Known gaps" for the two paths the hostless test target cannot cover.)
• 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. (10 violations, all pre-existing on develop; zero added.)
• I have updated the SDK documentation as well as the online docs. — DocC article added (Documentation.docc/CustomerCenter.md) and linked from SuperwallKit.md. The online docs page still needs writing.
• I have reviewed the contributing guide

cc @yusuftor @jakemor @anglinb

[greptile-apps]

PR author is not in the allowed authors list.

[pullfrog]

Important

The dismissal path looks broken for the primary presentation API: customerCenterDidDismiss() and the customerCenterClose event should never reach a delegate created the way the shipped example and the docs recommend. Details inline on CustomerCenterManager.swift.

Reviewed changes — full read of the 108-file diff at 2001d65, with the feature's five load-bearing files (config model, entry point, view model, path resolver, presentation builder) traced against their call sites and tests.

• Customer Center feature — a native @available(iOS 15.0, *) self-service screen presented via Superwall.shared.presentCustomerCenter(), CustomerCenterView, or CustomerCenterViewController, covering restore, manage/cancel, refund, change plan, contact support, exit surveys and purchase history.
• Public configuration surface — CustomerCenterConfiguration and its nested Screen/Path/FeedbackSurvey/Support/Appearance types, Codable and ObjC-bridged, resolved per-call → SuperwallOptions.customerCenter → .default.
• Product logic — CustomerCenterPathResolver (which rows appear, gated on store, active-ness, revocation, family sharing, refund window, iOS 17 change-plan availability) and PurchasePresentationBuilder (badges, status lines, per-product renewal dedupe), both table-tested.
• Delegate + callbacks — CustomerCenterDelegate, an ObjC mirror, a weak-holding adapter, and five SwiftUI .onCustomerCenter* modifiers accumulated through an environment box.
• Analytics — five new SuperwallEvent cases with ObjC mirrors and parameter payloads.
• Localization — 75 customer_center_* keys across all 41 .lproj bundles.
• Hooks outside the feature — SuperwallOptions.customerCenter, LogScope.customerCenter, DeviceHelper.appInstallDateValue, a lazy @MainActor DependencyContainer.customerCenterManager, and TransactionManager.tryToRestore(_:presentsFailureAlert:) defaulting to true.

A few things I checked and found clean, so they need no further attention: none of the five new events can implicitly trigger a paywall (canImplicitlyTriggerPaywall falls through to false); SuperwallOptions.encode(to:)'s explicit CodingKeys omits customerCenter, so nothing new is sent to the backend; every locale has all 75 keys with matching %@ counts and no stray %, so there is no String(format:) crash or argument-reordering hazard; and every StoreKit/SwiftUI API used is available at or below the version its guard asserts (verified against Apple's DocC JSON, including Mac Catalyst).

⚠️ Nothing exercises the seam between CustomerCenterManager and the view model's dismissal

The suite is genuinely good — the resolver and builder tables read like a spec, and the visibility-count tests pin the counter arithmetic exactly. But every dismissal test drives the view model directly with a live instance in hand, and CustomerCenterManagerTests separately asserts the delegate is released the instant the manager's cleanup runs. No test spans both, which is precisely why the inline CustomerCenterManager.swift finding passes CI today.

Technical details

# Add coverage for the manager → view model dismissal handoff

## Affected sites
- `Tests/SuperwallKitTests/CustomerCenter/ViewModel/CustomerCenterViewModelTests.swift:331-400` — drives `surfaceDidAppear`/`surfaceDidDisappear` on a view model the test itself retains; the debounce always finds a live `self`.
- `Tests/SuperwallKitTests/CustomerCenter/CustomerCenterManagerTests.swift:46-88` — asserts `weakDelegate == nil` immediately after `onDismiss` runs, with no view model in play.
- `Tests/SuperwallKitTests/CustomerCenter/UIKit/CustomerCenterDelegateAdapterTests.swift:33-47` — holds a strong local delegate for the whole test, so the adapter's `weak` capture is never observed going nil.

## Required outcome
- One test that presents through `CustomerCenterManager`, triggers the same dismissal cleanup the VC's `viewDidDisappear` would, waits past `dismissDebounceInterval`, and asserts the delegate's `customerCenterDidDismiss()` actually ran and a `customerCenterClose` event was tracked.
- The test must fail against the current code.

## Suggested approach (optional)
- Inject a short `dismissDebounceInterval` into the view model the manager builds (a test hook alongside `presentsAnimated`), keep a strong local reference to the probe delegate so the assertion is about delivery rather than lifetime, and assert on a mock tracker.

## Open questions for the human
- Is the hostless test target able to reach `viewDidDisappear` at all, or does this need to go through `presentedControllerForTesting?.onDismiss?()` plus an explicit `surfaceDidDisappear()` to simulate SwiftUI's teardown?

ℹ️ Two decisions the diff raises but can't settle

• Version stayed at 4.16.4. Following CLAUDE.md literally is correct here (a release was already staged on develop), but this adds a substantial new public API surface — CustomerCenterConfiguration, CustomerCenterDelegate, CustomerCenterView, CustomerCenterViewController, five SuperwallEvent cases, a View modifier — under a patch version. Worth an explicit maintainer decision rather than falling out of the changelog rule.
• 41 first-draft translations. Key parity and format specifiers are clean across every .lproj (I checked all 75 keys in all 41 files), so there's no correctness hazard; the remaining risk is purely wording, and the author's suggestion to route it through localization before release seems right.

ℹ️ Nitpicks

• Sources/SuperwallKit/CustomerCenter/Views/ManagementScreenView.swift:44 — ForEach(others.prefix(2)) silently truncates non-subscription purchases. With showsPurchaseHistory == false there's no "See all purchases" row, so anything past the first two becomes unreachable.
• Tests/SuperwallKitTests/CustomerCenter/ViewModel/CustomerCenterViewModelTests.swift:319 — comment says "the production default, 0.3s"; the default is now 0.6 (CustomerCenterViewModel.swift:67).

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

This clears the only strong reference to the delegate the moment viewDidDisappear fires, but CustomerCenterViewModel.dismiss() — the sole emitter of callbacks.didDismiss and the customerCenterClose event — doesn't run until the 0.6s visibility debounce elapses. By then the adapter's weak swiftDelegate is nil, so customerCenterDidDismiss() is silently dropped for exactly the usage the docs and CustomerCenterExampleDelegate recommend ("safe to create a fresh instance each time you present").

Technical details

# `didDismiss` and `customerCenterClose` are dropped on the `presentCustomerCenter` path

## Affected sites
- `Sources/SuperwallKit/CustomerCenter/CustomerCenterManager.swift:136-140` — `onDismiss` clears `retainedDelegate` synchronously.
- `Sources/SuperwallKit/CustomerCenter/UIKit/CustomerCenterViewController.swift:83-88` — `viewDidDisappear` invokes that closure at dismissal completion.
- `Sources/SuperwallKit/CustomerCenter/UIKit/CustomerCenterDelegateAdapter.swift:18-19,58-61` — the adapter holds the delegate `weak`, so once `retainedDelegate` is cleared the callback no-ops.
- `Sources/SuperwallKit/CustomerCenter/ViewModel/CustomerCenterViewModel.swift:337-343,345-352` — `dismiss()` only runs after `dismissDebounceInterval` (default `0.6`, `:67`), and the debounce `Task` captures `[weak self]`.

## Two independent failures, same root cause
1. **Delegate already released.** Certain: `retainedDelegate` is the only strong reference the SDK promises, and it is gone ~0.6s before the callback fires.
2. **View model likely deallocated.** `CustomerCenterManager.presentedController` is `weak` (`:16`), so UIKit's release of the dismissed VC deallocates the VC, its `UIHostingController`, and the view model. The debounce `Task`'s `guard let self` then fails and `dismiss()` never runs at all — meaning `customerCenterClose` is never tracked either, on any presentation path where the view model doesn't outlive the debounce.

## Required outcome
- `customerCenterDidDismiss()` reaches a delegate passed to `Superwall.shared.presentCustomerCenter(delegate:)`.
- `customerCenterClose` is tracked exactly once per presentation, on both the UIKit/manager path and the SwiftUI sheet path.
- The existing embedded-navigation behaviour (`usesExistingNavigation`, push/pop within the Customer Center must not fire a dismissal) is preserved.

## Suggested approach (optional)
- The debounce exists only because embedded mode can't distinguish a nav transition from a teardown. A `CustomerCenterViewController` being dismissed knows definitively: have `viewDidDisappear` call `viewModel.dismiss()` directly (it's already idempotent via the `didDismiss` latch) *before* invoking `onDismiss`, and leave the debounce as the embedded-mode-only fallback.
- Whatever the mechanism, clear `retainedDelegate` after the view model has fired, not before.

## Open questions for the human
- Should the SwiftUI sheet path get the same treatment, or is `@StateObject` teardown there slow enough that the 0.6s debounce reliably wins? That one I couldn't determine from the code alone.

[pullfrog]

This file is regenerated by xcodegen from project.yml, which scripts/build.sh, scripts/test.sh and the CI xcodegen-action all run — so this hand edit disappears on the next generation and the suite silently goes back to running in parallel. It needs to be parallelizable: false under targets.SuperwallKit.scheme.testTargets in project.yml instead. Separately, switching the whole suite to serial execution is a repo-wide policy change worth stating explicitly (which suites were racing?), since it costs CI time for every future test too.

[pullfrog]

This formatter (and the one in PurchaseDetailRows) uses Locale.current, while every string goes through CustomerCenterStrings.bundled() → LocalizationLogic.localizedBundle(nil), which resolves against deviceHelper.preferredLocaleIdentifier. An app setting SuperwallOptions.localeIdentifier gets translated copy with system-locale dates. CustomerCenterEnvironmentProviding.locale (CustomerCenterDependencies.swift:46,157) already carries exactly the right value but is never read by anything — wiring it into both formatters closes the gap and removes the dead protocol requirement.

[pullfrog]

Support, Appearance and ColorPair override isEqual but not hash, so these two lines mix identity hashes into a value-equality hash: two configurations that compare equal (e.g. .default twice, or an instance and its Codable round-trip) produce different hashes. Nothing in the SDK hashes this type today, but it's a public NSObject and so Hashable to consumers. Screen, Path, FeedbackSurvey and Option already pair both overrides — the three stragglers should match.

[pullfrog]

active is purchases.filter(\.isActive).compactMap(\.productId) — product identifiers, not entitlement identifiers — but SupportEmailComposer renders the field as - Entitlements:. Either populate it from customerInfo.entitlements or rename the field and label to product IDs, so support isn't reading mislabelled diagnostics.

[linear-code]

SW-5650