Docs
Browse documentation
NATIVE SDK

Surveys and feedback

Publish consent-based surveys and a moderated feedback board, with optional native presentation.

View Markdown

Opt in deliberately

Surveys and feedback are optional, disabled until the host opts in and the backend advertises surveys_v1 or feedback_board_v1. They use an existing authenticated support session; showing a survey or board does not silently register a guest. Start from your actual Help entry and configure the capabilities you intend to expose.

support.engagement.configure(surveys: true, feedback: true) { completionID in
    // Send this opaque ID to your authenticated host backend for validation.
    // It is not permission to grant a reward directly.
}

LobbySurveysView(client: support)
LobbyFeedbackBoardView(client: support)
// UIKit: LobbySurveysViewController(client:)
//        LobbyFeedbackBoardViewController(client:)

Draft, publish, then ask

An authorized app owner/admin can create and edit a survey draft and publish an immutable revision. Up to 20 surveys per app can contain one to ten questions: bounded integer ratings, one choice from two to ten options, or bounded text up to 1,000 characters. Customers see a published revision, not a moving draft. Submission requires explicit consent and is scoped to the app, environment and customer. Private survey answers are not public support messages or feedback-board posts.

Keep pending answers safe

The native form retains its exact original body, key and published survey snapshot in scoped Keychain storage when the result is uncertain. Retrying sends the same request; it does not create another answer. A paused or removed survey does not hide that pending request. Definite validation failures remain recoverable for editing with fresh consent. Confirmed completion from another device never exposes another account’s answers. Resetting the account clears private engagement state and fences late callbacks.

Moderate before publishing

Customer proposals require consent that the team may publish their title and text after moderation. New proposals remain pending and public:false. The board returns only published title, text, status and actual vote totals; customer names, emails and private proposals stay out of its public response. Operators can publish or hide an item and mark it open, planned, in progress or completed. Those are team-supplied roadmap statuses, not proof of a shipped feature. Keep personal and account details out of proposals.

Votes need a real choice

A vote requires an explicit tap. Verified-account voting is the default. An owner may enable guest votes tied to the current support identity. A caller-supplied installation identifier cannot take ownership of another guest’s vote; this still does not verify a person’s identity. Votes, proposals and uncertain requests remain scoped to their original customer/app/environment; a disappearing public item is not a reason to replace an uncertain request with a new key.

Survey completion is not reward fulfillment

submitSurvey returns a LobbySurveyCompletion with reward status none or host_validation_required. The optional completion callback carries only an opaque ID. Your authenticated host backend must sign a distinct short-lived survey-reward assertion and call POST /v1/host/survey-rewards/claim. Its response deliberately says fulfilled:false. Your backend deduplicates actual fulfillment using claim.id; the app callback, identity JWT and a guest’s later sign-in cannot grant credits, purchases or subscription time. Never tie a reward to an App Store rating or use survey sentiment to choose review requests.

Cards and verification boundaries

With engagement_actions_v1, a survey action card pins the published survey ID/revision and presents the native form only after a customer tap and accepted current-session ticket. Opening a form does not submit it. Registered permission cards call a host-owned explanation/preferences handler; they never silently request an OS permission. Source tests and simulator compilation do not establish a merchant installation, real reward fulfillment, OS permission approval or a completed App Store review.

Built from the implementation’s current capabilities. Check release status before production use.