Skip to main content
Then you can set the delegates for handling events and customizing screens as follows - (optional):
After initializing the SDK, you can move forward and display the No-Codes screen:
If you want to use Qonversion No-Codes with your own purchase infrastructure, see how you can do it in two simple steps.

Loading screens before presentation

By default, showScreen is fire-and-present: it presents a loading view immediately and fetches the content afterwards, so your app learns the outcome through delegate callbacks only after the screen is already on screen. If you want to decide up front — an “ask-first” flow — use loadScreen. It awaits the screen’s availability and data (from cache or network) before anything is presented, so you can either present the screen or show your own fallback UI without the SDK loading view ever appearing. A successful load warms the shared screens cache, so the following showScreen call with the same context key renders from cache.
The returned screen exposes its id, contextKey, and the typed default variables configured on it in the builder (see Reading default variables below). The error lets you branch on the failure: a screen not found error (NoCodesError.type == .screenNotFound on iOS, error code ScreenNotFound on Android) means the screen is genuinely absent for that context key — show your fallback; any other code indicates a transient network or load failure — you may retry.
loadScreen is an optional, additional entry point — not a prerequisite for showScreen. Screens marked as preloadable in the No-Codes Builder are fetched automatically at SDK initialization (see Screens Preloading), and showScreen works on its own.Two minor differences from a direct showScreen call: loadScreen does not flush pending user properties, so the targeting basis may differ slightly; and on-demand loads cache the screen without pre-embedded images (image embedding is applied during init-time preloading only).
Available starting from the following SDK versions:

Reading default variables

The screen returned by loadScreen carries the typed default variables configured on it in the No-Code Builder — defaultVariables. Each variable has a kind:
  • custom — a Screen Variable authored in the builder’s Variables section;
  • product — a product slot: the variable key is the slot name and the value is the default Qonversion product ID assigned to it;
  • selectedProduct — the screen’s Default Product (Product Slots panel → Default Product): the Qonversion product ID selected by default when the screen opens. Read it via the typed shortcut screen.defaultSelectedProductId — no key needed.
Each variable preserves its configured native type (boolean / string / number) instead of being stringified:
For example, to read a variable by key, the default product of a slot, and the screen’s default selected product. Keys are only unique within a kind — a custom variable and a product slot may share a name — so the by-key lookup accepts an optional kind filter:
defaultVariables is an empty list when the screen has none configured (or on older payloads), so it is always safe to iterate. The kind set may grow — values unknown to your SDK version arrive as .unknown / Unknown instead of failing the load.
These values are the defaults configured on the screen, read back at load time. Conditional slot overrides and runtime mutations inside the running screen are not reflected, and they are not the same as the custom variables you pass into a screen from your app (see Passing custom variables).

Passing custom variables

You can pass dynamic values from your app into a No-Code screen and reference them in conditional logic, dynamic text, or component visibility rules. Variables are scoped to a specific contextKey, so different screens can receive different values, and each value is queried at the moment a screen is about to be shown — including sub-screens reached via in-screen navigation. For native SDKs, implement a delegate that returns a Map/dictionary keyed by contextKey. For cross-platform SDKs, pass the values directly to showScreen.
Values must be strings. Inside the screen, variables are injected into the JavaScript context via window.noCodesSetVariable(name, value) and then become available in conditional logic, dynamic text bindings, and visibility rules.

Delegates

Earlier, we discussed how to set delegates. Now, let’s explore their purpose.

Main delegate

The main delegate is needed so that you can receive messages about what is happening during the execution of No-Codes, as well as to provide us with the screen from which to start navigation and display the No-Codes screen. Let’s go through this step by step.

Unity Warning

Unity NoCodes delegate events are delivered on iOS only. On Android, the No-Codes screen runs as a separate Activity on top of Unity’s Activity and Unity’s game loop is paused while the screen is shown, so delegate events do not fire.
controllerForNavigation (iOS only)
In this function, you must return a UIViewController from which we will start displaying the No-Codes flow. If you do not provide one, we will take the topmost screen in the current stack.
Screen shown event
This function notifies about the display of a screen with a specific identifier.
To read the screen’s configured default variables and product slots, load the screen entity via loadScreen and use its defaultVariables — see Reading default variables.

Action execution start event

This function notifies you that executing the action you set up through our dashboard has begun.

Action execution fail event

This function notifies you that executing the action you set up through our dashboard has failed.

Action execution finish event

This function notifies you that the action you set up through our dashboard has been executed.

Custom action received event

This function is called when a Custom action is triggered on the screen. Custom actions are not executed by the SDK — implement your own handling here; the value string configured in the builder identifies which action was triggered. The screen stays open; close it using NoCodes.shared.close() if needed. If no value was configured, an empty string is delivered. Available starting from the following SDK versions:

Screen finished event

This function notifies that the No-Codes flow has been completed and No-Codes has been finished.

Screen loading failed

This function is called when No-Codes screen loading has failed.

Localization

By default, No-Code screens automatically detect the device’s system language and display the appropriate localization if available. You can override this behavior by setting a custom locale, which takes priority over the automatic system language detection. The locale should be in standard format (e.g., "en", "en-US", "de", "de-DE"). Pass nil/null to reset to the system default locale. Setting locale during initialization:
Setting locale after initialization:

Theme

No-Code screens support light and dark themes. By default, screens automatically adapt to the device’s system appearance (Auto mode). You can override this behavior by setting a specific theme, which takes priority over the automatic system theme detection.
Currently, the theme only affects skeleton loader colors, with full theming support for the No-Code Builder coming soon
Available theme modes:
  • Auto (default) - Follows the device’s system appearance
  • Light - Forces light theme regardless of device settings
  • Dark - Forces dark theme regardless of device settings
Setting theme during initialization:
Setting theme after initialization:

Screen customization

Use the screen customization delegate to customize the screen opening animation. For example, to enable or disable the animation (iOS only), specify the type of opening: push/popover (iOS only)/full screen. You can also pass a statusBarHidden flag that determines whether to show or hide the status bar when displaying the screen (iOS only). For example:

Custom loading view

By default, the SDK displays a skeleton loading view while the No-Code screen is loading. You can replace it with your own custom loading view by implementing the noCodesCustomLoadingView() method in the screen customization delegate. Your custom view must conform to the NoCodesLoadingView protocol (iOS) or implement the NoCodesLoadingView interface (Android). The SDK calls startAnimating() when the loading begins and stopAnimating() when the screen content is ready.
If noCodesCustomLoadingView() returns nil / null, the default skeleton loading view will be used.

Screens Preloading Success and Failure Actions