User feedback incompatible with multiple windows

[noahsmartin]

Description

The user feedback API is not very mobile app friendly, it's built around a floating button that appears over the apps UI. This API is incompatible with multi-window apps such as on iPad or when using a display because it picks the first available UIWindowScene.

Additionally, the UX of this API is a non-starter for most mobile apps, although it is common for web apps. There is an option to connect the feedback UI to a custom UIButton, but that also is not ideal because it is not flexible enough to support common mobile feedback UX that is not based on a button such as shake for feedback. To fix these issues we should redesign the API to make sense for a mobile app.

The simplest solution is to have a public UIViewController subclass which users can instantiate and display however they want. This would solve all of the above issues. Additionally, all configuration related to user feedback should be removed from the SDK init options. Instead configuration should be specified on the instance of the UIViewController. That is a cleaner API and makes it is possible to create different designs for the feedback page depending on how the developer presents it. Another way to know the current API is not working well is we have to have extra options for every use case. For example, we had to build support into the SDK + an option for showing the feedback form when the user takes a screenshot or shakes for feedback. By providing the ViewController based API we can remove all this bloat and instead let users show it however they want.

When we fix this the existing feedback APIs for showing/hiding the floating button and configuring the view should be marked deprecated.

Alternatives:

• Introduce a "presentation anchor" like AuthenticationServices does using this delegate method. However, this is less flexible and more confusing for developers than a simple UIViewController. This kind of API is better for when the framework needs to decide how to present it (modal/push/etc), which is not the case for the feedback UI.
• A static showFeedback method on SentrySDK, Android does this: https://github.com/getsentry/sentry-java/pull/4559/changes but it doesn't solve the main issue being reported here, that it would be incompatible with multiple windows because the context about where to present the view controller is lost with a simple no-arg static method. The UIViewController API suggested here is more standard practice for iOS apps and would have less issues.

[linear]

COCOA-1115

[philprime]

From internal communication:

@philprime on Jan 5th, 2026:

I feel like we are mixing up two issues here:

1. The floating button widget is bad practices and needs to go. Alternative would be offering the presentationAnchor so it's not randomly injected but users can control where to display the widget button
2. The Sentry Feedback UI(ViewController) can not be displayed as a view controller with full control over presentation.

I think we should deprecate and eventually remove the floating button widget so users need to do either:

1. Create a SentryUserFeedbackFormController and display it manually using traditional UIKit/SwiftUI presentation methods
2. Create a public API SentrySDK.feedback.showUI() which uses a presentation anchor per scene so that would even allow multiple feedback forms on multi-tasking apps.

In my personal use case of Flinky I would prefer option 2, because then I just need to add (menu)buttons all over the app as I drafted in this PR and only have to implement the feedback anchor once.
But I do see full control for the user in option 1, so I would propose we do both.