Fix build error on Xcode 26.0 from ambiguous CGFloat arithmetic

[yusuftor]

Summary

A user reported that SuperwallKit 4.16.2 fails to build on Xcode 26.0 with:

• DeviceHelper.swift:494: ambiguous use of operator '*'
• DeviceHelper.swift:498: cannot convert return expression of type '()' to return type 'DeviceHelper.UITraits?'

The fontScale expression mixed a CGFloat (UIFontMetrics.scaledValue(for:)) with Double/Int literals, relying on the implicit CGFloat↔Double conversion. Xcode 26.0's type-checker can't rank the candidate solutions and reports the * as ambiguous; later toolchains (26.6) resolve it, which is why it wasn't reproducible locally. The second error is a cascade of the first: with the closure body poisoned, DispatchQueue.main.sync(execute:) falls back to the () -> Void overload.

Converting once with Double(scaledValue) removes the implicit conversion entirely, leaving every toolchain exactly one solution. Behavior is identical.

Bumps the version to 4.16.3.

Testing

Not testable by a unit test: the bug is a compile-time type-checker failure on an older toolchain, not a behavior change — the expression produces identical values before and after. Verified by building the framework and running the full test suite (919 tests, 0 failures) on Xcode 26.6 / iOS 26.5 simulator.

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 PR fixes an Xcode 26.0 compilation ambiguity by explicitly converting the scaled font value to Double.

• Preserves the existing fontScale calculation and serialized value.
• Bumps the SDK and CocoaPods versions to 4.16.3.
• Adds the corresponding 4.16.3 changelog entry.

Confidence Score: 5/5

The PR appears safe to merge with no actionable defects identified.

The explicit conversion matches the destination model’s Double type, remains lossless on supported targets, and the version is consistently updated across all required release files.

Important Files Changed

Filename	Overview
Sources/SuperwallKit/Network/Device Helper/DeviceHelper.swift	Makes font-scale arithmetic unambiguously Double without changing its value or serialization contract.
Sources/SuperwallKit/Misc/Constants.swift	Updates the runtime-reported SDK version from 4.16.2 to 4.16.3.
SuperwallKit.podspec	Keeps the CocoaPods package version synchronized at 4.16.3.
CHANGELOG.md	Documents the Xcode 26.0 build fix in the new 4.16.3 release entry.

_{Reviews (1): Last reviewed commit: "fix: build error on Xcode 26.0 from ambi..." | Re-trigger Greptile}

[pullfrog]

ℹ️ The fix itself is correct and complete — one deferrable observation about CI coverage below.

Reviewed changes — a patch release carrying a single compile-fix plus the standard version bump.

• Double(scaledValue) in makeUITraits — removes the last CGFloat from the fontScale expression in DeviceHelper.swift:494, so the SE-0307 implicit CGFloat↔Double conversion no longer has to fire and the solver has exactly one candidate. Numerically identical: UITraits.fontScale is already Double, and CGFloat == Double on every platform the SDK supports.
• Version bump to 4.16.3 — Constants.swift (still landing on line 21, as the file's own header comment requires), SuperwallKit.podspec, and a new CHANGELOG.md entry. All three sites CLAUDE.md requires; no stale 4.16.2 references remain.

I checked two things beyond the diff, both of which came back clean:

• Is the one-line fix complete? I swept Sources/SuperwallKit/** for the same shape — a CGFloat operand mixed with untyped numeric literals flowing into a Double-typed destination with no explicit cast. There are no other occurrences. Every other CGFloat arithmetic site resolves in a CGFloat context (CGSize, CGAffineTransform.scaledBy, PaddingListener.maxPadding, CAShapeLayer radius math) or already carries an explicit conversion, and UIFontMetrics has exactly one call site in the SDK.
• Does Double(...) actually disambiguate, or just move the problem? It eliminates it. With no CGFloat left in the expression, 16.0, 100, and .rounded() all unify on Double and no conversion is inserted at all. Forcing one operand's type early is the mitigation Swift core-team members recommend for this class on the forums, so this is the canonical shape rather than an ad-hoc workaround.

One note on the changelog wording, not worth changing: I could not find an Apple or swiftlang issue, or an Xcode 26.0/26.1 release-note entry, documenting this as a versioned regression. SE-0307 shipped in Swift 5.5, so the ambiguity mechanism is not new to 6.2 — most likely a solver-ranking shift tipped this particular expression over. Nothing contradicts the report, and "Fixes a build error when compiling the SDK with Xcode 26.0" is accurate as a statement of the observed symptom.

ℹ️ No CI job builds against the toolchain that breaks

Every macOS workflow pins xcode-version: latest-stable, so nothing in CI exercises Xcode 26.0 and this regression could silently return. This is the second toolchain-specific build break in three patch releases — CHANGELOG.md 4.16.1 records the billing-plan compiler-directive fix "so that the SDK builds in Xcode version 26.4" — and both were reported by users rather than caught by a check. Not blocking this PR, and I'd suggest handling it separately rather than expanding scope here.

Technical details

# Add a build job on the oldest supported Xcode

## Affected sites
- `.github/workflows/build-platforms.yml:26` — `xcode-version: latest-stable`
- `.github/workflows/tests.yml:32` — `xcode-version: latest-stable`
- `.github/workflows/emerge-tools-upload.yml:19` — `xcode-version: latest-stable`

## Required outcome
- A compile failure that only reproduces on the oldest Xcode the SDK claims to
  support should fail a check, not a customer's build. Both 4.16.1 and 4.16.3
  shipped fixes for breaks of exactly this shape.

## Suggested approach (optional)
- Add a compile-only matrix entry to `build-platforms.yml` pinning an explicit
  older version (e.g. `xcode-version: '26.0'`) alongside `latest-stable`. Build
  only — no need to duplicate the test suite, since these are type-checker
  failures, not behavioral ones.

## Open questions for the human
- What *is* the oldest supported Xcode? That answer sets the pin, and it isn't
  currently stated in `README.md`, `Package.swift`, or the podspec.

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