[itsjavi]

Ref ENG-3427

What & why

Was: in-app surveys on iOS rendered at the default text size whatever the respondent chose under Larger Text. WKWebView never applies Dynamic Type to web content.

Now: the survey's text follows Dynamic Type both ways, up to 200% at the accessibility sizes, on iPhone and iPad. The default size is unchanged.

Android needs no change: its WebView already scales page text by the system font scale unless the app calls setTextZoom, which the Android SDK never does (AwSettings.updateFontScaleLocked, aw_settings.cc → SetTextZoomFactor).

Where to look

• WebView/SurveyTextScale.swift — Dynamic Type → -webkit-text-size-adjust, and the 200% cap
• WebView/FormbricksViewModel.swift — where the value enters the page, read from the presenter's traits
• WebView/SurveyWebView.swift — mobile content mode, so full-size iPads honour the value

Design points worth checking

Why -webkit-text-size-adjust. WebKit multiplies it into every computed font size (updateFontForTextSizeAdjust), and em lengths resolve against the adjusted size (resolveEm). The renderer compiles its spacing to em, so on iOS padding and gaps grow with the text while pixel-sized parts keep theirs. Android's text zoom grows only the text. WKWebView.pageZoom was the alternative: it scales everything, shrinks the layout viewport to ~190 CSS px at 2×, and would need the card rect for touch passthrough rescaled.

The 200% cap. It is Android's largest font scale and WCAG 1.4.4's resize target. Every question type checked fits a 402 pt iPhone card at 2× (screenshots); the matrix scrolls sideways. iOS goes to ~3× (AX5), so the largest accessibility sizes get 200%. It's a product call — one constant, maximumFactor.

Scale source. UIFontMetrics(forTextStyle: .body) — Apple's API for scaling custom font sizes — so xxxLarge gives 131%, slightly under the system body text's 135%.

Whose setting. The category comes from the trait source PresentSurveyManager already passes for the appearance: the host's key window (no overlay) or the presenting view controller (overlay). A host that overrides Dynamic Type there with traitOverrides caps the survey too. A SwiftUI-only .dynamicTypeSize(...) cap never reaches UIKit traits, so the SDK can't see it; such apps need to set the same cap in traitOverrides. Without a trait source the page keeps the default size.

Mobile content mode. Full-size iPads load WKWebView content in desktop-class mode, where WebKit ignores the percentage. The survey WebView asks for .mobile. At the default size the iPad render is pixel-identical to main; the user agent now says iPad instead of Mac.

Default size is untouched. At "Large" the template emits auto, the property's initial value, not 100%. Pixel-identical to main on iPhone and iPad.

Read once, at presentation. A Dynamic Type change while a survey is open applies to the next survey.

The renderer must not set it. It doesn't today: its only rule is #fbjs html { -webkit-text-size-adjust: 100% }, which matches nothing. If that selector were ever "fixed" to html, it would override this.

Coverage

Behaviour	Level
Default size leaves the page as before (auto)	unit (mutation): testTheDefaultSizeLeavesThePageUntouched, return "\(percent)%" unconditionally at SurveyTextScale.swift:43
Text follows the setting, smaller and larger	unit (mutation): testTheTextFollowsTheSettingInBothDirections, return 1 at SurveyTextScale.swift:36
Accessibility sizes stop at 200%	unit (mutation): testTheAccessibilitySizesStopAtTheCap, drop the min at SurveyTextScale.swift:36
The presenter's setting reaches the page's root element; no presenter gives auto	unit (mutation): testTheSurveyPageCarriesThePresentersSetting, read UIApplication.preferredContentSizeCategory instead at FormbricksViewModel.swift:26 (red)
The survey WebView asks for mobile content	unit (mutation): testTheSurveyWebViewAsksForMobileContent, drop the line at SurveyWebView.swift:33 (red)
Real WKWebView: text follows Dynamic Type, default size unchanged	manual: iPhone 17 Pro and iPad Pro 13" simulators, iOS 26.5, renderer built from packages/surveys; computed styles read in the page, 0 pixels differ at Large (screenshots)
Long headline, matrix, ranking, NPS at 200%: card scrolls, Finish reachable	manual: iPhone 17 Pro simulator (screenshots)
A host window's traitOverrides caps the survey	manual: system at AX5, host window at Large → auto (screenshot)
Android text follows font scale up to 200%	manual: Chromium source reading + emulation; no device

Rerun: xcodebuild test -scheme FormbricksSDK -destination 'platform=iOS Simulator,name=iPhone 16,OS=latest' -only-testing:FormbricksSDKTests/SurveyTextScaleTests

Screenshots — iOS 26.5 simulators, the SDK in a host app, the survey renderer built from packages/surveys

main vs this PR, same survey and host, only the SDK differs.

iPhone 17 Pro	main	This PR
Large (default) → auto
xxxLarge → 131%
AX5 → 200%, choice
AX5, long headline
AX5, matrix
AX5, ranking
AX5, NPS

iPad Pro 13"	main (desktop-class mode)	This PR (mobile mode)
Large (default)
AX5 → 200%

System at AX5, host caps it	This PR
Host window traitOverrides at Large → survey at default size
SwiftUI .dynamicTypeSize(...DynamicTypeSize.large) only → not visible to UIKit, survey at 200%

Open gaps

• Headline line spacing is doubled on iPhone at large sizes (renderer). WebKit scales em line-heights twice under a percentage text-size-adjust: once through the adjusted font, once by the factor. The renderer's leading-* compile to calc(var(--spacing) * N) with --spacing: .25em, so at 200% headlines get a 96 px line-height for 32 px text instead of 48 px, and buttons 64 px. Unitless and pixel line-heights scale correctly, and the iPad in mobile mode is unaffected. The fix is unitless leading-* in packages/surveys; follow-up, not in this PR.
• The matrix scrolls sideways at 200%, and its row labels leave the view when it does. Usable, not comfortable; a sticky label column in the renderer would fix it.
• The React Native and Flutter SDKs' iOS WebViews have the same gap; not in this PR.
• No device run, and Android at 200% is still unchecked on a device.
• CI: PassthroughPresentationTests' 3 s wait times out intermittently on main (comments below).

Breaking changes

• This is a breaking change

No public API change. Surveys on full-size iPads now load in mobile content mode, so their user agent says iPad instead of Mac; the layout at the default size is unchanged.

---

Note

AI model used — claude-opus-5-5.

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: 0c25bfd6-dd5d-4e3c-9fc2-44ce573c3895

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[itsjavi]

build-and-analyze has two failures on dc81277:

• SurveyTextScaleTests.testTheTextFollowsTheSettingInBothDirections — this PR's, fixed in the next push. The test pinned xxxLarge at 135%, the system body-size ratio (23/17). UIFontMetrics scales a custom 17 pt size to 131% there. The test now asserts the relationship (above 1×, below the cap) instead of a guessed table value.

• PassthroughPresentationTests.testOverlaySurveyIsPresentedOnTheTopMostViewController — not this PR's. It fails identically on main at b782cb0 (run 37435222335) and in fix: let host-app touches through when the survey has no overlay [ENG-1818] #57's merge-queue run. Both logs show the main thread blocked for 9–20 s right after WebKit's Networking process launches, which happens when the first WKWebView is created on a cold simulator. The predicate is true by then, but wait(for:timeout: 3.0) has already expired on wall-clock time. No fix exists yet. Proposed patch, outside this PR's scope:

  -        wait(for: [presented], timeout: 3.0)
  +        // The first WKWebView in the test process cold-starts WebKit's helper processes, which can
  +        // block the main thread for many seconds on CI simulators.
  +        wait(for: [presented], timeout: 30.0)

  (Tests/FormbricksSDKTests/PassthroughPresentationTests.swift:129). The CI run triggered by the next push will show whether it passes this time.

---

Generated by Claude Code

[itsjavi]

build-and-analyze on b8d1f34: all 144 tests pass, including the presentation test that timed out last run. The job then fails in SonarCloud Scan: Failed to import SonarSource public key from all keyservers.

Not this PR's: #61 (dependabot, merged as b782cb0) moved sonarqube-scan-action from v6.0.0 to v8.2.2. The comment above that pin explains why it is held at v6.0.0: v8 verifies a GPG signature against keyservers this harden-runner macOS runner can't reach. So main fails the same step.

Ported the fix, the revert of that one line, in 9c767a1. It becomes a no-op once main carries the same revert. Dependabot will propose v8 again on its next weekly run unless .github/dependabot.yml gets an ignore for SonarSource/sonarqube-scan-action major updates. I've left that out to keep this PR's scope.

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud