User Feedback: app start and UI test regressions in 9.19.1

[sentry-junior]

Customer report: enabling User Feedback on Cocoa SDK 9.19.1 increased app start time and caused UI test failures. Rolling back to 9.18.0 resolved both. They remain on CocoaPods (last published version is 9.19.1) and cannot move to SPM yet.

Verified

• CocoaPods publishing stopped after v9.19.1; docs mark CocoaPods as no longer supported
• Latest stable SDK is 9.23.0 via SPM / pre-built XCFramework
• User Feedback APIs landed around 9.18.0–9.19.x; nothing in the 9.19.1→9.23.0 release notes clearly documents a fix for app-start or UI-test regressions tied to User Feedback

Unknown

• Exact User Feedback configuration (widget vs programmatic present, shake/screenshot triggers, etc.)
• Repro steps, devices/OS versions, and measured app-start delta
• Whether the same symptoms still occur on 9.23.0 (XCFramework or SPM)
• Whether the UI test failures are SDK-driven (e.g. shake/screenshot/form presentation) or app-specific

Related

• Possibly adjacent to broader v9 cold-start work in Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896, but this report is scoped to 9.18.0 → 9.19.1 with User Feedback enabled

Workaround suggested to customer

• Try latest pre-built XCFramework from GitHub releases while SPM migration is incomplete, and re-validate app start + UI tests before assuming the regression is fixed

Requested by David Quintas via Junior.

--

View Junior Session in Sentry

[linear-code]

COCOA-1744

[philippsuess]

Investigation update — need more context to reproduce

Hey, I tried to investigate and reproduce this, but I was unable to. We need more context before we can reliably reproduce it.

What would help most:

1. A minimal repro from the customer/user who hit this — a small sample project or zip that shows the app-start regression with User Feedback enabled. This is the single most valuable thing.
2. A quick isolation test on a recent SDK version (ideally the latest): does the regression still happen when they disable User Feedback? If it goes away, it's User-Feedback-specific; if it persists, they're seeing a more general v9 app-start regression and this is likely a different problem.

Any surrounding detail also helps: exact User Feedback config (auto-injected widget vs. presenting the form themselves, shake/screenshot triggers), UIKit vs. SwiftUI, where SentrySDK.start is called, how they measured app start, and whether options.debug was on.

---

Detailed investigation notes (for whoever picks this up)

Summary

• Two reported symptoms: (A) increased app-start time and (B) UI-test failures, both when enabling User Feedback, both fixed by rolling back 9.19.1 → 9.18.0.
• Symptom B (UI interference): mechanism confirmed. Symptom A (app-start time): could not reproduce in the environments available to me.
• Scope note: nothing has shipped since that addresses this — the relevant hotspots are unchanged through the latest release (9.24.0 / current main).

What we confirmed (Symptom B — UI interference)

• With SentryUserFeedbackWidgetConfiguration.autoInject = true (the SDK default; the sample app overrides it to false), the SDK eagerly creates and shows the feedback widget's overlay UIWindow + RootViewController during SentrySDK.start, on the main thread, before any explicit showWidget() and before the host root VC appears.
• Evidence (launch logs, SDK source unmodified): SentryUserFeedbackWidget.RootViewController instantiated at launch; a ui.lifecycle breadcrumb shows the overlay window live at windowLevel = 1.0 (.normal + 1), distinct from the app's key window at 0.0 — all with zero showWidget() call.
• Code path: SentryUserFeedbackIntegrationDriver.swift:42-59 → SentryUserFeedbackWidget.swift:42-50 (window.isHidden = false) → default _autoInject = true at SentryUserFeedbackWidgetConfiguration.swift:12.
• Caveat: I could not get this extra window/button to surface in screenshot / snapshot_ui accessibility captures (likely because the overlay window never becomes key and XCUITest-style snapshotting walks the key window's tree). Log evidence is solid; the visual/accessibility-tree confirmation is still open. An extra non-key window at level 1.0 is itself a plausible cause of UI-test breakage.

What we could NOT reproduce (Symptom A — app-start time)

• Simulator A/B (iOS-Swift sample, iOS 18.6, 10 launches per config, app.lifecycle root span): Feedback ON w/ autoInject=true = 357.02 ms; Feedback OFF = 357.25 ms. Delta −0.23 ms, well inside run-to-run jitter (±7–9 ms stdev). Not significant.
• Per-integration install timing: SentryUserFeedbackIntegration installs in ~0.3 ms — negligible.
• Why this is not conclusive:
  • Simulator disables the on-device dyld protocol-conformance cache, so it cannot faithfully measure any swift_conformsToProtocol-driven cold-start cost (see below / Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896). Wrong environment for this symptom.
  • The app.lifecycle span measures the SDK's own init work — it likely does not capture the UIKit cost of rendering the eager overlay window / first-frame commit, which is what a user perceives as "app start."

Root-cause candidates identified (none confirmed for Symptom A)

Reviewed all 84 commits in 9.18.0..9.19.1, filtered to code that runs at start:

1. internal_getKeyWindow() on the App-Hang path — ref: add accessor for application key window #8280 (8c39e1ae2), + ref: add prefix to HangTracker related types #8282. Runs by default (App Hang tracking on), independent of feedback. 9.18.0 read the key window inline; 9.19.0 routes it through internal_getKeyWindow(), which wraps the lookup in dispatchSyncOnMainQueue(..., timeout: 0.01). Verified in the impl (_SentryDispatchQueueWrapperInternal.m:88): if already on the main thread it runs inline (no block); it only blocks (≤10 ms) when called off-main. hangTracker is a lazy initialized on first access — so whether this can block launch depends on the thread at first-touch. Most suspicious default-path change; not yet verified.
2. Feedback fixes fix(feedback): Prevent feedback form on external displays #8071 (c977ee103) + fix(feedback): Keep the User Feedback screenshot trigger active after form dismissal #8048 (6ae36812d). Feedback-gated (match the customer's config). fix(feedback): Prevent feedback form on external displays #8071 rewrote presenter window selection (reads windowScene?.session.role); fix(feedback): Keep the User Feedback screenshot trigger active after form dismissal #8048 made the screenshot observer persistent. Tied to Symptom B, low app-start cost.
3. ObjC→Swift growth / Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896 (cold-start regression from Swift metadata / swift_conformsToProtocol). The range adds many Swift files (HybridSDK/SentryInternal*Api.swift feat: add root-level methods and raw address properties to SentryInternalApi #8097, SentryMutex, etc.), growing __swift5_proto. Shipping arm64 binary has ~228 protocol-conformance records — small in absolute terms (a large app has tens of thousands), so the SDK alone is unlikely to dominate a 40–65% regression, but enabling User Feedback pulls its Swift-heavy slice into the launch path. Diffuse, not a single commit.

Ruled out

• fix: unsynchronized debug-mode access in binary image cache #8309 (fix: unsynchronized debug-mode access in binary image cache) — considered and rejected. It only moved the isDebug read inside the lock; the expensive duplicate-SDK scan is debug-only (options.debug), already present at 9.18.0 (unchanged workload), and dispatched off-main. Cannot affect a production (debug=false) cold start.
• Session Replay run-loop rework perf(session-replay): Reduce capture stutters #7851 — big churn but only runs if Session Replay is enabled; report is scoped to User Feedback.

String(describing:) audit (adjacent to #7896)

• The maintainer note on Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896: conformance-cache cost is largely a local-debug artifact (disabled on simulator/Instruments, present in prod), but "there should still be no reason to use String(describing:)."
• SDK-start path proper is clean; the User Feedback module has no String(describing:). Exposure is indirect via UI/breadcrumb tracking wired up at install.
• Notable, still present at latest main: SwiftDescriptor.swift:13 (String(describing: type(of:)), reused by VC perf tracker / view hierarchy / breadcrumbs — highest leverage), SentryTracedView.swift:151 (generic Content type reflection — exactly the Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896 pattern), SentrySanitizerUtils.swift:25, SentryBreadcrumbTracker.swift:297. Also: SentrySDKLog message params are not @autoclosure, so interpolated log strings evaluate even when logging is disabled.
• Nothing here has been fixed in any shipped version.

Environment blockers

• Could not run a production-representative cold-start trace: only physical device available was offline, and ETTrace wasn't installed. Real-device + ETTrace is the definitive test for Symptom A and Cold-start regression in v9 caused by Swift runtime metadata / protocol conformance overhead #7896.

Suggested next steps

1. Get a minimal repro from the reporter (top priority).
2. Ask them to test a recent SDK with feedback disabled to confirm whether it's feedback-specific vs. a general v9 regression.
3. Static thread-trace of hangTracker first-init during start to confirm/clear candidate Downgraded OS requirements and upgraded dependencies #1 (ref: add accessor for application key window #8280) from code alone.
4. Real-device ETTrace comparison (9.18.0 vs 9.19.1, feedback on/off) once a device is available.

[NinjaLikesCheez]

Blocked as we're waiting for a response

[philprime]

Closing this due to inactivity. If this is still relevant for you, feel free to comment and provide current information.