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.
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).Reading default variables
The screen returned byloadScreen 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.
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 specificcontextKey, 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.controllerForNavigation (iOS only)
Screen shown event
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
Action execution fail event
Action execution finish event
Custom action received event
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
Screen loading 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:
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. 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
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 astatusBarHidden 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 thenoCodesCustomLoadingView() 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