On this page

Using the iOS SDK

Survicate allows you to launch precisely targeted surveys inside your app. In Survicate Panel, you'll be able to define conditions that your users have to meet for the surveys to appear. Users matching conditions defined in the Survicate panel will see the survey automatically. Here's a list of conditions you can use to target your surveys:

  • Name of the screen that a user currently sees
  • Any application event
  • User attributes and identities
  • Device language
  • Operating system

Make sure to list all the screens and events described in your application. Once you got this covered, you or any person responsible for creating and managing surveys will be able to trigger surveys from the Survicate panel with no need for you to update the application.

Warning The SDK utilizes UserDefaults to store information used by the targeting engine described in this section. Clearing UserDefaults will cause the targeting system to malfunction; f.e. by showing the same survey twice to a single user.

Targeting a survey by the screen name

A survey can appear when a user is viewing a specific screen. For example, a survey can be triggered to show up on the application's home screen after a user spends more than ten seconds there. To achieve that, you need to send information to Survicate about the user entering and leaving a screen.

Screen name is case sensitive. If there's any discrepancy between what's declared in the ‘Triggers’ tab of the Target section in the Survicate panel and the application code, the survey will not appear.

Events-based survey targeting

You can log custom user events throughout your application. They can later be used in the Survicate panel to trigger your surveys. Your survey will show instantly after an event occurs in your app.

Event name and property keys are case sensitive. If there is any discrepancy between what's declared in the ‘Triggers’ tab of the Target section in the Survicate panel and the application code, the survey will not appear.

User identification & attributes

You can pass user attributes to Survicate as an additional layer of information about your users. Attributes can be used to:

  • Identify respondents (by default survey responses are anonymous).
  • Target surveys to specific users with Audience filters.
  • Filter survey results.
  • Recall information in survey questions (e.g. include user name).

Bear in mind that user attributes are cached, you only have to provide them once, e.g. when user logs in, not after each initialize(). You can also change their values at any time (which may potentially trigger showing the survey).

Attribute types

  • String: any text, e.g. user name or e-mail.
  • Double: a decimal value.
  • Boolean: a logic value.
  • Date: a Date that can be used in date or time interval filters.

Special attributes

  • user_id: This corresponds to the "Logged-in status" in the panel's Audience filter. A user is considered logged-in when a trait with the "user_id" key has been set on the device, regardless of the value.

  • first_name, last_name, email: If none of these is specified, a response will be marked as Anonymous in the panel.

Additional notes

  • You can freely use custom attribute keys without the need to register them anywhere.

  • In some panel functionalities (e.g. autocompletion), the attribute key will be available only after a survey response with the given attribute is uploaded (unless the key was added in the panel manually). By that time, the trait is saved only locally on the user's device.

  • Note that the predefined attribute classes (UserTrait.userId, UserTrait.firstName, etc.) have been deprecated in version 4.0. Instead, you should use the UserTrait(withName, value) constructor. You will find migration details in the deprecation messages.

  • In objective-c implementation you should use string values for every attribute type (e.g. @"true" for boolean attribute).

Response attributes

Response attributes are session-scoped attributes attached to survey responses. Unlike user attributes, they are cleared at the start of each new app session and are sent to Survicate along with the user's survey answers.

To update a response attribute, call the method again with the same name and a new value. To clear an attribute, pass an empty string as the value.

ResponseAttribute accepts the following parameters:

  • name (required): The key that identifies the attribute.
  • value (required): The attribute value. Pass an empty string to clear an existing attribute.
  • provider (optional): The name of the external service where this data comes from (e.g., "hubspot", "intercom"). This helps integrations identify and match your survey respondents with their profiles in that service.

Attribute types

  • String: any text value.
  • Double: a decimal value.
  • Boolean: a logic value.
  • Date: a Date.

Note: In Objective-C, ResponseAttribute only accepts String values.

Setting the locale

Survicate SDK automatically detects the device locale using NSLocale.preferredLanguages and uses it both to choose the translation of a survey and to evaluate any Device language targeting filters.

If your app allows users to change the locale independently of the system settings, you can override the default by calling:

The argument must be a valid IETF language tag such as:

  • A two‑letter ISO 639 code (e.g., "en", "fr")
  • A three-letter code for languages without the two-letter equivalent (e.g., "haw", "yue")
  • A language tag with region (e.g., "en-US", "pt-BR")

Note: The specified locale setting applies only to the current application session. To preserve the preference after an app restart, make sure to call setLocale(...) again, anytime after Survicate.init(...).

Theme mode

When your survey has a theme with both light and dark modes, the SDK will select the proper variant following the system setting by default.

Optionally, you can enforce a specific theme mode with the setThemeMode method:

Custom fonts

Using the SurvicateSdk.shared.setFonts method you can specify custom fonts for survey presentation. You need to provide a PostScript font name for each font style required by the SDK.

Font names must be PostScript font names — not the file name or display name.

Custom fonts must be registered in your app's Info.plist file and included in your bundle before they can be used with setFonts(). Unregistered fonts will cause the SDK to fall back to the default Survicate fonts.

Listeners

SDK allows you to utilize event listeners. You may find them useful to trigger actions in your application based on actions performed by respondents. Here's a list of events you can subscribe to:

  • survey_displayed - occurs when survey is loaded and appears in the User Interface
  • question_answered - occurs after a question is answered ( Survicate stores incomplete survey submissions )
  • survey_closed - occurs when a user closes the survey using the close button
  • survey_completed - occurs when a user finishes the survey.

SurvicateAnswer object properties (QuestionAnsweredEvent.answer)

PropertyTypeDescription
typeStringAnswer type. One of: ['text', 'single', 'multiple', 'smiley_scale', 'rating', 'csat', 'numerical_scale', 'nps', 'date', 'form', 'matrix', 'button_close', 'button_next', 'button_link'].
idIntegerAnswer ID. Applicable only for types: ['single', 'smiley_scale', 'csat', 'rating', 'numerical_scale'].
idsInteger[]Selected answer IDs. Applicable only for type = ['multiple'].
valueString?Text representation of an answer, e.g. "Happy" for smiley scale. A nil value in case of a skipped question. Not applicable for call-to-action answers: ['button_close', 'button_next', 'button_link'].

Note: We currently support passing the id, ids and value properties only for the cases enlisted in the table above. You can expect to stumble upon answer objects that consist only of the type property.

Reseting user data for testing purposes

If you need to test surveys on your device, the reset() method can be useful. It clears all user data stored on the device — including survey views, attributes, and information about answered surveys — as well as the current in-memory state of the SDK.