4.16.2

[yusuftor]

Changes in this pull request

Promotes develop → master for the 4.16.2 patch release.

Enhancements

• Adds the user's system-wide text size (Dynamic Type) as three device attributes for use in paywalls and audience filters: fontScale, fontSize, and preferredContentSizeCategory.
• Links subscriptions to the user server-side after a successful purchase or restore.

Fixes

• Fixes network requests that can never succeed, such as those with an invalid API key, taking up to a minute to fail instead of failing straight away. Timeouts and server errors still retry as before.
• Fixes failed network requests being reported as a decoding error rather than the HTTP error that actually occurred.
• Fixes issue where the paywall debugger wouldn't work for accounts with many paywalls.

Release contents

Version	4.16.2 (Constants.swift, SuperwallKit.podspec, CHANGELOG.md all match)
Commits	34 since master
PRs included	#488, #489, #490, #494

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

🤖 Generated with Claude Code

Greptile Summary

This patch prepares the 4.16.2 SDK release.

• Adds Dynamic Type attributes to device and paywall data.
• Links subscriptions server-side following successful purchases and restores.
• Revises network retry and HTTP-error handling.
• Adds scalable paywall-debugger listing and identifier resolution.
• Refactors optional permission integrations to avoid unused privacy API signatures.
• Updates Superscript, release metadata, tests, and CI validation.

Confidence Score: 4/5

The PR is not yet safe to merge because transaction redemption can still associate a completed purchase or restore with an identity selected after the transaction.

Purchase and restore completion launch unstructured redemption tasks, while redemption request construction reads the live IdentityManager values; an immediate identify or reset can therefore change which user receives the server-side subscription association.

Files Needing Attention: Sources/SuperwallKit/StoreKit/Transactions/TransactionManager.swift; Sources/SuperwallKit/Web/WebEntitlementRedeemer.swift

Important Files Changed

Filename	Overview
Sources/SuperwallKit/Network/Device Helper/DeviceHelper.swift	Caches UI trait snapshots and performs the underlying UIKit reads on the main thread for background device-attribute callers.
Sources/SuperwallKit/StoreKit/Transactions/TransactionManager.swift	Adds asynchronous server-side subscription redemption after successful purchase and restore handling.
Sources/SuperwallKit/Network/Custom URL Session/TaskRetryLogic.swift	Classifies terminal HTTP responses so unrecoverable client failures bypass retry backoff.
Sources/SuperwallKit/Debug/DebugViewController.swift	Reworks debugger paywall selection around the V2 preview-list and identifier-resolution endpoints.
Sources/SuperwallKit/Permissions/PermissionHandler.swift	Refactors permission handling to keep unused privacy-sensitive API signatures out of shipped binaries.

_{Reviews (2): Last reviewed commit: "Update CHANGELOG.md" | Re-trigger Greptile}

[pullfrog]

ℹ️ No new issues in the privacy-signature hardening — the refactor is behavior-preserving and the one behavior change is an improvement. Two housekeeping items below.

Reviewed changes — the delta since the previous pullfrog review at 84e7b13, i.e. the 5 commits of #496 that stop Apple's permission API names reaching the compiled framework.

• Four @objc Fake* shims deleted — FakeContactStore, FakeLocationManager, FakeAudioSession and FakeTrackingManager mirrored Apple's selectors verbatim, so their names landed in __TEXT,__objc_methname. Each *Proxy now takes the resolved class through an init(xClass: AnyClass? = NSClassFromString(mangled.rot13())) seam and guards on nil instead.
• @objc dropped from the *SelectorName properties on all four proxies, with a comment on each explaining why they must stay Swift-only.
• Continuation wrappers renamed — requestRecordPermission/requestAccess/requestTrackingAuthorization became requestPermission/requestPermission/requestAuthorization, because withCheckedContinuation's function: String = #function default expands the enclosing name into a __cstring literal.
• Two plaintext literals mangled — PlistKey.tracking is now ROT13-decoded at read time, and LocationPermissionDelegate derives its KVC key from LocationManagerProxy.mangledAuthorizationStatusSelector rather than "authorizationStatus".
• New CI gate — scripts/scan-privacy-signatures.sh greps __objc_methname, __objc_classname and __cstring for a 14-name denylist, run in tests.yml against the framework the test step just built at -derivedDataPath .build.
• Tests reshaped around the missing-class path — each deleted fake's suite becomes a *MissingClassTests suite driving the new init seam with nil, plus a test pinning the tracking plist key's decode.

I checked the mangling claim end-to-end rather than taking it on trust: every ROT13 constant round-trips to the right Apple name, no denylisted name survives as a plaintext literal anywhere in Sources/ (only inside // ROT13("…") comments), the only @objc left in Permissions/ is the pair of CoreLocation delegate callbacks the script deliberately exempts plus three @objc enum status mirrors, no continuation site's #function still expands to an Apple name, and nothing in source, tests or the regenerated project.pbxproj still references a deleted fake. The scan exits 2 when the binary or the sections are missing, so it can't silently pass.

The refactor is sentinel-for-sentinel equivalent to the fake fallbacks (-1 for contacts and microphone, notDetermined for tracking and location) with one deliberate improvement: requestWhenInUseAuthorization() / requestAlwaysAuthorization() now return false when CoreLocation is absent, so PermissionsHandler+Location resumes .unsupported where the fake reported success and left the continuation waiting for a callback that never came.

ℹ️ The release PR body no longer describes the release it's promoting

This description still says "34 commits since master" and lists only #488, #489, #490 and #494, but the branch now carries 52 commits and the 4.16.2 CHANGELOG section includes entries from #497 (Main Thread Checker fix) and #496 (privacy signatures). On a develop → master promotion the body is the release summary, so it's worth reconciling before the merge.

Technical details

# Release PR body is stale relative to the branch

## Affected sites
- PR #498 description, "Release contents" table — `Commits | 34 since master` (actual: 52) and
  `PRs included | #488, #489, #490, #494` (missing #496, #497).
- PR #498 description, "Fixes" list — has no line for #496's two CHANGELOG entries, and its
  Main Thread Checker line matches `CHANGELOG.md` but isn't attributed to #497.

## Required outcome
- The body's commit count, included-PR list and fix list match `CHANGELOG.md`'s 4.16.2 section
  and the actual branch contents at merge time.

ℹ️ Nitpicks

• scripts/test.sh — CI now scans .build/Build/Products/Debug-iphonesimulator/SuperwallKit.framework/SuperwallKit, but the repo's own test command doesn't pass -derivedDataPath .build, so a developer can't reproduce the new gate without hand-writing the xcodebuild invocation. Adding -derivedDataPath .build (already .gitignored) plus a trailing call to the scanner would close that gap.
• scripts/scan-privacy-signatures.sh:12-16 — the header says the names "come back in two ways" and that it "scans those two sections", but there are three of each: the #function mechanism this PR actually fixed is only described down at the denylist (:39-42), and the implementation reads __objc_methname, __objc_classname and __cstring.

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

[pullfrog]

ℹ️ No new issues in the pre-launch read gate — the design holds up under tracing. One testability gap and three housekeeping notes.

Reviewed changes — the delta since the previous pullfrog review at b29cf44, i.e. the 7 commits of #501 that stop the SDK touching UIKit before the application object exists. Three files: DeviceHelper.swift, DeviceHelperTests.swift, one CHANGELOG line.

• One launch gate in front of every appearance-adjacent read — isUIKitReadSafe (UIApplication.sharedApplication != nil || Bundle.main.bundleURL.pathExtension != "app") is consulted first inside both makeUITraits() and makeScreenMetrics(), which now return nil rather than touching UIScreen / UIFontMetrics / trait collections before UIApplicationMain has run.
• Screen metrics moved from init-time lets to a self-healing cache — screenWidth / screenHeight / devicePixelRatio became computed properties over a @DispatchQueueBacked screenMetrics?, serving ScreenMetrics.placeholder while the gate is shut and filling on the first allowed read.
• Two healing routes for a too-early init — an empty uiTraits cache takes a blocking fill off-main instead of scheduling a refresh, and the notification handler now also fills screenMetrics when it's still nil.
• The gate is injected per instance — an isUIKitReadSafe: () -> Bool init parameter, because the pre-UIApplicationMain state can't be recreated in-process; UITraits, ScreenMetrics and both make* readers dropped private for the same reason.
• Tests for the gate and the healing — both readers returning nothing behind a shut gate, exact-value screen metrics read off the main thread, and a Gate-driven instance suite walking placeholders → first-allowed-read → notification-driven fill.
• CHANGELOG — one line for the accent-color fix.

I checked the two claims this design rests on rather than taking them on trust. Coverage: DeviceHelper really is the only appearance-adjacent UIKit touch on the synchronous main-thread configure() path — everything else that reads UIScreen / UIColor / UIFontMetrics or constructs a view (PaywallViewController, SWWebView, ShimmerView, SurveyManager, DebugViewController, TestMode/*, ButtonFactory) is reachable only through @MainActor factories, which cannot execute before the run loop starts, and Network.init's UIApplication read sits inside a Task { @MainActor }. Cost of deferring: the placeholders don't actually reach the wire, because every off-main reader (Network.matchMMPInstall:486-488, makeHeaders' X-Device-Interface-Style, getTemplateDevice()) goes through DispatchQueue.main.sync, which can't complete until the main queue is being drained — by which point the application object exists and the read returns real values. So placeholders only surface for a main-thread read inside the pre-launch window, and there's no synchronous public API exposing these attributes. The cooperative-pool threads that hop parks are bounded by core count, and no cyclic wait exists inside the SDK, so it resolves as soon as launch progresses.

ℹ️ Nitpicks

• Tests/SuperwallKitTests/Network/DeviceHelperTests.swift:351 (also :369, :403) — _ = dependencyContainer is the lifetime anchor for a container the helper only holds unowned, but it sits before the assertions, so ARC is free to release it there. Nothing dangles today because no assertion reaches factory; withExtendedLifetime(dependencyContainer) { … } would make the anchor actually hold before someone adds a getTemplateDevice() assertion to one of these.
• Tests/SuperwallKitTests/Network/DeviceHelperTests.swift:426-430 — instance_fillsCachesOnNotification's trait assertions only hold on iOS 17+: below 17 currentUITraits bypasses the cache entirely, so re-shutting the gate before reading yields UITraits.unavailable rather than the notification's fill. CI runs OS=latest so it passes — it's one more cost of the version fork in the open thread above.
• Sources/SuperwallKit/Network/Device Helper/DeviceHelper.swift:482-484 — "Activation also … fills the screen-metrics cache" attributes the fill to didBecomeActiveNotification, but both notifications share one handler, and instance_fillsCachesOnNotification deliberately relies on UIContentSizeCategory.didChangeNotification doing it.

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

[pullfrog]

ℹ️ No new issues in the #502 follow-ups — both trait changes are correct and the tests behind them now have real failure power. Two documentation nits inline.

Reviewed changes — the delta since the previous pullfrog review at a8dd696, i.e. the 4 commits of #502 that close out the three open threads from earlier reviews. Four files: DeviceHelper.swift, DeviceHelperTests.swift, MicrophonePermissionTests.swift, one CHANGELOG line.

• Font attributes are now single-source — makeUITraits() scales through UIFontMetrics.default.scaledValue(for:compatibleWith:) against a UITraitCollection(preferredContentSizeCategory:) built from the category it already resolved, so fontSize, fontScale and preferredContentSizeCategory in one snapshot can no longer disagree, and nothing depends on the thread-local UITraitCollection.current.
• One trait read path on every OS version — the #available(iOS 17.0, *) fork in currentUITraits is gone; iOS 13-16 now serves the cache with refresh-on-read instead of reading live, removing the blocking DispatchQueue.main.sync that makeHeaders' X-Device-Interface-Style and getTemplateDevice() each paid per call below iOS 17.
• The launch gate's deciding clause became testable — isUIKitReadSafe delegates to a pure isUIKitReadSafe(hasApplication:bundleURL:), with three tests pinning all three arms including the app-bundle-before-launch one that actually prevents #493.
• Test expectations no longer inherit the fault they're meant to catch — a shared expectedScaledValue(for:) helper computes expectations with the same explicit-trait overload production uses.
• Microphone proxy tests pinned deterministically — sharedInstance_returnsNonNil became sharedInstance_matchesWhetherTheClassResolves, tying both sides to whether AVAudioSession resolves rather than to the runner image, plus new tests decoding all four ROT13 constants the way the Contacts, Location and Tracking suites do.

I checked the scaledValue(for:compatibleWith:) substitution against Apple's documentation rather than assuming it was a pure refactor: UITraitCollection.init(preferredContentSizeCategory:) is iOS 10+ / Mac Catalyst 13.1+ and creates a collection containing only that trait, scaledValue(for:compatibleWith:) is iOS 11+ / Mac Catalyst 13.1+, and no unspecified trait in that collection changes the scaling — so the numeric values reaching audience filters are unchanged for every real content size category, with the undefined-current dependency removed. I also traced the cache lifecycle with the version fork gone: uiTraits is only ever assigned a non-nil reading, it stays nil solely while the gate is shut, and an empty cache read off-main still takes the blocking fill — so pre-launch placeholder behaviour on iOS 13-16 is identical to before, and the only new cost is the documented one-read staleness after an in-place light/dark flip. The new plaintext Apple names in MicrophonePermissionTests land in the test bundle, and scan-privacy-signatures.sh scans the framework binary passed as $1, so the CI gate is unaffected.

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

[pullfrog]

ℹ️ No critical issues in the locale preload — the WebKit injection path checks out. Two housekeeping items, one of which stops the checked-in Xcode project building.

Reviewed changes — the delta since the previous pullfrog review at c8edc89, i.e. #503 plus its changelog line. Four files: DevicePreloadScript.swift (new), SWWebView.swift, DevicePreloadScriptTests.swift (new), one CHANGELOG.md line.

• Added a document-start locale preload — DevicePreloadScript.source(deviceLocale:) JSON-encodes ["deviceLocale": locale] and wraps it as window.__SW_DEVICE_PRELOAD__ = {…};, returning nil if the payload can't be encoded.
• Wired it into the paywall webview — SWWebView.init's factory widened to FeatureFlagsFactory & DeviceHelperFactory and registers the script as a WKUserScript (.atDocumentStart, forMainFrameOnly: true) alongside the existing paywallMessageHandler registration, so paywall.js can localize on first paint instead of waiting for template_variables.
• Pinned the encoding — three tests covering the exact emitted string, JSON escaping of an en"};alert(1);// breakout attempt, and raw UTF-8 passthrough for a non-ASCII identifier.
• CHANGELOG — one enhancement line for the locale injection, folded into the 4.16.2 section.

I checked the load-bearing WebKit contract rather than assuming it: addUserScript here runs after super.init(frame:configuration:), which Apple documents as the point where the configuration is copied. WebKit's WKWebViewConfiguration.copyWithZone: delegates to APIPageConfiguration::copyDataFrom, a member-wise copy of a ref-counted userContentController, so the copy shares the same WKUserContentController instance and post-init registration does reach the live webview — which is also exactly what the adjacent, demonstrably working paywallMessageHandler registration depends on. The script therefore applies to the later load(request) and to the loadFileURL archive path, and the paywall renders in the main frame so forMainFrameOnly: true is right. The injected value is also consistent with what arrives later: makeDeviceInfo().locale is deviceHelper.localeIdentifier, the same source getTemplateDevice() uses for DeviceTemplate.deviceLocale, so the preload honors SuperwallOptions.localeIdentifier and can't disagree with template_variables.

ℹ️ The Xcode project wasn't regenerated for the two new files

SuperwallKit.xcodeproj/project.pbxproj is committed in this PR (regenerated for #489's model files), but it contains no reference to DevicePreloadScript.swift or DevicePreloadScriptTests.swift. CI is unaffected because tests.yml runs the xcodegen action before xcodebuild, so this won't show up as a red check — but opening the checked-in project fails to compile SWWebView.swift, since DevicePreloadScript isn't a member of the SuperwallKit target, and the new test isn't in the test target either.

Technical details

# `project.pbxproj` is stale relative to #503's new files

## Affected sites
- `SuperwallKit.xcodeproj/project.pbxproj` — no `PBXFileReference` / `PBXBuildFile` /
  `PBXGroup` entry for `Sources/SuperwallKit/Paywall/View Controller/Web View/DevicePreloadScript.swift`
  (compare `PaywallSummary.swift`, which #489 did regenerate in).
- `SuperwallKit.xcodeproj/project.pbxproj` — same for
  `Tests/SuperwallKitTests/Paywall/View Controller/Web View/DevicePreloadScriptTests.swift`
  (compare `NetworkErrorTests.swift`).

## Required outcome
- The committed project builds `SWWebView.swift` and runs `DevicePreloadScriptTests` without a
  developer having to regenerate first, i.e. `xcodegen` output is committed alongside the source
  files it enumerates, as it was for #489.

ℹ️ Nothing in the repo verifies the preload contract the CHANGELOG advertises

The global name (window.__SW_DEVICE_PRELOAD__) and payload key (deviceLocale) are a contract with paywall.js, which lives outside this repo, and the failure mode is silent: if the web bundle doesn't read the global yet, or resolves translations from preferredLocale / preferredLanguageCode rather than deviceLocale, the change is inert while the CHANGELOG tells developers first-paint localization now works. Worth confirming the web side is deployed before this release goes out.

Technical details

# Preload contract is unverifiable from the SDK repo

## Affected sites
- `Sources/SuperwallKit/Paywall/View Controller/Web View/DevicePreloadScript.swift:27` — emits
  `window.__SW_DEVICE_PRELOAD__` with a single `deviceLocale` key.
- `CHANGELOG.md:11` — advertises the resulting first-paint behavior as shipped in 4.16.2.

## Open questions for the human
- Is paywall.js's support for `window.__SW_DEVICE_PRELOAD__` already live for every paywall version
  this SDK release can render, or does the changelog line need to wait?
- Do translations resolve from `deviceLocale`, or from `preferredLocale` /
  `preferredLanguageCode`? `DeviceTemplate` carries all three, and only `deviceLocale` is preloaded.

ℹ️ Nitpicks

• Sources/SuperwallKit/Paywall/View Controller/Web View/SWWebView.swift:119-133 — the tests cover the string builder, but nothing covers the wiring that can actually regress (registered at all, .atDocumentStart, locale taken from makeDeviceInfo()). webView.configuration.userContentController.userScripts is directly assertable, and WebEntitlementRedeemerTests already constructs an SWWebView with dependencyContainer, so the setup cost is small.

  ^{｜ Fix it ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

[pullfrog]

ℹ️ No new issues in the Superscript bump — the pin, the tag, the checksum and the published pod all line up. One changelog wording suggestion inline, two verification items below.

Reviewed changes — the delta since the previous pullfrog review at 4dfa44e, i.e. the single commit 1a052ce. Eight files, all release metadata; no SDK source changed.

• Superscript pinned to 1.0.15 — Package.swift (.exact), Package.resolved, project.yml, the xcodeproj Package.resolved and Examples/Advanced's lockfile all move from 1.0.14 (abb2c8c) to 1.0.15 (c3d1ee8).
• CocoaPods caught up two versions — the podspec's Superscript dependency goes 1.0.13 → 1.0.15, closing the SPM/CocoaPods drift that existed on master.
• Xcode project regenerated — project.pbxproj now carries DevicePreloadScript.swift and DevicePreloadScriptTests.swift, which closes the stale-project item from the 4dfa44e review.
• CHANGELOG — one new fix line for the audience-filter crash.

I checked the bump end to end rather than taking the version strings on trust. Tag 1.0.15 in superscript-ios-next points at exactly the pinned revision c3d1ee8, and its only change over 1.0.14 is the libcel release URL plus checksum — the Swift binding target is untouched, so there is no API surface for the SDK to adopt. Superscript 1.0.15 is published on CocoaPods trunk (15:02 UTC, ten minutes before this commit), and 1.0.14 never was, which is why the podspec sat on 1.0.13; upstream deliberately skipped Rust 1.0.14, so the two-version pod jump carries no undocumented evaluator changes. CELEvaluatorTests drives the real FFI, so a UniFFI checksum mismatch against the new binary would fail this repo's own test run rather than ship. And every .swift file under Sources/ and Tests/ now has both a file reference and a build-phase entry in the regenerated project.

The upstream fix itself is the right shape for #500: execute_with no longer unwrap()s a failed argument resolution, parse_to_ast returns an error instead of panicking, and all four FFI entry points are catch_unwind-guarded under panic = "unwind" — so CELEvaluator's existing .failure → noMatch path finally gets reached instead of the process aborting underneath it.

ℹ️ Nothing in this repo pins the crash fix this release is named for

#500 was 531 crashes across 72 users in 27 minutes from one dashboard typo, with no client release involved — and after this merge the only thing preventing a recurrence is a version string in Package.swift. CELEvaluatorTests already drives the real evaluator, so a case asserting that daysSince(app_install) >= 1 degrades to noMatch would abort the test run on 1.0.14 and pass on 1.0.15, which is exactly the failure power needed to catch a future downgrade or an upstream regression in the panic guard.

Technical details

# No SDK-side regression test for the #500 evaluator abort

## Affected sites
- `Tests/SuperwallKitTests/Paywall/Presentation/Audience Logic/ExpressionEvaluator/CELEvaluatorTests.swift`
  — 11 tests, all with well-formed expressions. The closest case,
  `evaluateExpression_expressionFalse` (`a == "b"`), is an undeclared reference at the top level,
  not an unresolvable argument inside a computed-property call, so it never hit the panic.
- `Package.swift:22` — `.exact("1.0.15")` is currently the only artifact encoding the fix.

## Required outcome
- A test in `CELEvaluatorTests` fails (by aborting) against Superscript 1.0.14 and passes against
  1.0.15, so the guarantee is enforced by this repo's CI rather than by a pinned version alone.

## Suggested approach
- Add a case mirroring #500's filter verbatim and assert the non-matching outcome:
  `.setting(\.expression, to: "(size(device.activeEntitlements) == 0) && (daysSince(app_install) >= 1)")`
  → `.noMatch(source: .expression, experimentId: rule.experiment.id)`.
- `device.daysSince(app_install) >= 1` is the second reported spelling (it is what the dashboard
  displays for a stored `device.daysSince_app_install`), so it is worth a second case.

ℹ️ The bump flips the Rust panic strategy on every Apple slice, including the ones this PR's checklist hasn't ticked

Superscript 1.0.15 changes libcel from panic = "abort" to panic = "unwind" and rebuilds the visionOS and watchOS slices with -Zbuild-std=std,core,alloc,panic_unwind. Those -Zbuild-std targets are where a panic-strategy change is most likely to surface as a link or launch problem, and they are also the unchecked boxes in this PR's checklist — so a Catalyst and visionOS run is worth doing before the promotion rather than after.

Technical details

# Verify the non-iOS slices against the relinked `libcel`

## Affected sites
- `Package.swift:22` / `SuperwallKit.podspec:40` — both now resolve a `libcel.xcframework` built
  with `panic = "unwind"`; the previous binary was `panic = "abort"`.
- `Package.swift:9-13` — the package declares `.iOS(.v13)`, `.macOS(.v10_12)` and `watchOS "6.2"`,
  so the changed slices are all in the supported set.

## Required outcome
- The demo project links and launches on Mac Catalyst and visionOS (and watchOS, if a slice ships
  there) against 1.0.15, with the corresponding checklist boxes ticked from an actual run.

## Open questions for the human
- Does anything in the release process size-check the framework? Unwind tables make `libcel`
  larger than the `abort` build; worth knowing the delta before customers ask.

ℹ️ Nitpicks

• Examples/Basic/Basic.xcodeproj/project.xcworkspace/xcshareddata/swiftpm/Package.resolved still pins Superscript 1.0.14 / abb2c8c, while Examples/Advanced's lockfile was bumped in this same commit. Cosmetic — Xcode re-resolves it against the root package's .exact("1.0.15") on first open — but the two example lockfiles now disagree in the tree.

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

[pullfrog]

✅ No new issues found.

Reviewed changes — the delta since the previous pullfrog review at 1a052ce, i.e. three commits. Three files, no SDK source changed.

• Regression test for the #500 evaluator abort — evaluateExpression_unresolvableFunctionArgument_noMatch drives the real evaluator with daysSince(app_install) >= 1 and asserts noMatch(source: .expression, …), closing the coverage item from the 1a052ce review.
• Examples/Basic's lockfile caught up — Superscript 1.0.14 → 1.0.15 (c3d1ee8), so both example lockfiles now agree with the root .exact("1.0.15") pin.
• RevenueCat bumped in Examples/Advanced — 5.81.2 → 5.83.2, example app only.

I checked that the new test is a real guard rather than a passing formality, since that was the whole point of the ask. The expression is #500's shape: daysSince resolves (the computed/device maps are built from ComputedPropertyRequestType.allCases), while app_install is a placement name that never lands in the attributes map, so the bareword really is an undeclared reference inside a declared property call — and the standalone form is stronger than the && composition I suggested, which could short-circuit past the call entirely. Against the pinned 1.0.15 the Rust side returns {"Ok":{"type":"Null"}} — the upstream fix commit superwall/superscript@7739ad1 adds a test pinning that reply for this verbatim expression — so EvaluationResult decodes .success(.null), falls to CELEvaluator's default: branch and produces exactly the asserted outcome, deterministically and with no host-callback round trip. Against 1.0.14 the same input hits the unconditional .unwrap() under panic = "abort", so a downgrade or an upstream regression aborts the test-runner process; worth knowing that the signal is a crashed run rather than a red assertion.

One behavioural detail that falls out of that: because the reply is Ok(Null) and not Err, the .failure branch's Logger.debug(logLevel: .warn) never fires for this class of dashboard typo — the filter silently never matches, with nothing in the logs. Not worth changing (warning on the whole default: branch would also fire for every legitimate false), but it's the diagnostic a developer will look for next time.

On the RevenueCat bump: every release between 5.81.2 and 5.83.2 is scoped to RevenueCatUI paywalls, remote config and the new checkpoints feature, none of which RCPurchaseController.swift, Delegate.swift or SuperwallAdvancedApp.swift touch; 5.83.2 satisfies the example's own upToNextMajorVersion from 5.16.0; and nothing in the SDK, the podspec or any workflow depends on RevenueCat, so the change is contained to that lockfile.

The two pre-merge items from earlier reviews are unchanged and not repeated here: the description still describes a 34-commit, four-PR release, and the Mac Catalyst / visionOS boxes are still unticked against the relinked libcel.

  ^{｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}