Conditional logic allows you to dynamically change the appearance of any component on your paywall or onboarding screen based on runtime context — device info, selected product, user properties, or custom screen variables.
For example, you can highlight a specific product’s price in bold when the user selects it, hide an element on Android, or change the background color for dark mode users.
Make sure your Qonversion SDK is updated to the latest version that supports conditional logic.
See the SDK Requirements section below.
How It Works
Each component on your screen has style blocks (Typography, Size, Spacing, Background, etc.). You can attach conditional rules to any style block. Each rule contains:
- Conditions — when should this rule apply (e.g., “Platform equals iOS AND Theme equals dark”)
- Style overrides — what properties to change when the conditions are met (e.g., set font-size to 24px and color to white)
At runtime, the Qonversion SDK provides the context (device info, user data, product details), and the conditional logic evaluator checks each rule top-to-bottom. The first matching rule wins — its overrides are applied, and subsequent rules are skipped.
If no rule matches, the component keeps its default styles.
Step-by-Step Example: Changing Typography for iOS Dark Mode
Let’s walk through a real example. We’ll change the title text style when the user is on iOS in dark mode — applying a different font, size, weight, and color to ensure the text looks great on dark backgrounds.
1. Select the component
Click on the text component you want to add conditional logic to. In this example, we select a title text on the paywall screen.
2. Open the Conditional Rules modal
In the right sidebar, find the Typography style block. Hover over the block header — a lightning bolt icon will appear. Click it to open the Conditional Rules modal.
3. Add a new rule
Click Add Rule at the bottom of the modal. A new empty rule appears with a condition group and a style overrides section.
4. Set the conditions
We need two conditions combined with AND logic:
First condition:
- Variable: select
Platform from the Device category
- Operator: select
equals
- Value: select
iOS
Second condition:
- Variable: select
Theme from the Device category
- Operator: select
equals
- Value: select
dark
This means: “Apply this rule when the user is on iOS AND using dark mode.”
5. Set the style overrides
In the Overrides section below the conditions, configure the typography changes:
| Property | Value |
|---|
| Font family | System UI |
| Font size | 22 px |
| Font weight | Semi Bold (600) |
| Color | #f3e5e5 (light warm tone) |
| Line height | 20 px |
6. Save and preview
Click Apply to save the rules. The lightning bolt on the Typography block now shows a badge with the rule count.
To test it, open the Preview Conditions Panel (the test tube icon in the header). You can manually change the Platform and Theme variables to see how the component reacts in real time.
Conditions In Detail
Condition Groups: AND / OR
Conditions within a rule are organized in groups. Each group has a logical operator:
- AND — all conditions in the group must be true
- OR — at least one condition must be true
Click the and/or label between conditions to toggle the group operator.
Groups can be nested up to 2 levels deep, allowing complex expressions like:
(Platform equals iOS AND OS Version greater_or_equal 16.0)
OR
(Platform equals Android AND OS Version greater_or_equal 13.0)
Available Variables
Device
| Variable | Type | Example values |
|---|
| Platform | String | iOS, Android |
| OS Version | Version | 16.0, 14.5.1 |
| Language | String | en, fr, de |
| Locale | String | en_US, fr_FR |
| Theme | String | light, dark |
| App Version | Version | 1.0.0, 2.3.1 |
| Country | String | US, GB, DE |
Products
| Variable | Type | Description |
|---|
| Selected Product | String | The product ID the user currently has selected |
| Has Any Intro | Boolean | Whether any product has an introductory offer |
| Per-product Has Intro | Boolean | Whether a specific product has an intro offer |
| Per-product Intro Type | String | free_trial, pay_as_you_go, or pay_up_front |
User
| Variable | Type | Description |
|---|
| Entitlements | Array | List of user’s active entitlements |
| Has Any Entitlement | Boolean | Whether the user has at least one active entitlement |
| Is First Launch | Boolean | Whether this is the user’s first app launch |
| Days Since Install | Number | Number of days since the app was installed |
Available Operators
| Operator | Works with | Description |
|---|
| equals | All types | Exact match (case-insensitive for strings) |
| not equals | All types | Inverse of equals |
| in | String, Version | Value is one of a comma-separated list |
| not in | String, Version | Value is not in the list |
| contains | Array, String | Array includes the value, or string contains substring |
| does not contain | Array, String | Inverse of contains |
| greater than | Number, Version | Numeric or semantic version comparison |
| less than | Number, Version | Numeric or semantic version comparison |
| greater or equal | Number, Version | Numeric or semantic version comparison |
| less or equal | Number, Version | Numeric or semantic version comparison |
| is empty | Array, String | Array has no elements, or string is empty/null |
| is not empty | Array, String | Array has elements, or string is non-empty |
Version comparisons (for OS Version and App Version) use semantic versioning — each segment is compared numerically. For example, 16.0 is greater than 9.3.6.
Rule Priority
Rules are evaluated top to bottom within each style block. The first rule whose conditions evaluate to true is applied — all subsequent rules are skipped.
This means you should order your rules from most specific to least specific:
Rule 1: Platform = iOS AND Theme = dark -> white text, large font
Rule 2: Platform = iOS -> dark text, large font
Rule 3: (default — no conditions match) -> keeps default styles
Activating and Deactivating Rules
Each style block has an Active toggle in the Conditional Rules modal header. When toggled off:
- All rules are preserved (not deleted)
- Rules are not evaluated at runtime
- The lightning bolt indicator remains visible but rules have no effect
This is useful for temporarily disabling conditional logic without losing your configuration.
Testing with Preview Panel
You don’t need to publish your screen to test conditional logic. The No-Code Builder has a built-in Preview Conditions Panel that lets you simulate any combination of variables and instantly see how your rules affect the screen — right inside the editor.
How to open the panel
- Make sure you have at least one conditional rule configured on any component
- Switch to Preview mode using the toggle in the builder header
- The Preview Conditions Panel automatically appears on the left side of the screen
The panel lists every variable used in your conditional rules across all components on the current screen.
Testing variables
Each variable has an appropriate input control depending on its type:
- Dropdowns — for variables with predefined values (Platform, Theme, Selected Product, Intro Type, etc.). Just pick a value from the list
- Checkboxes — for boolean variables (Has Any Intro, Has Any Entitlement, Is First Launch, etc.). Toggle on or off
- Text inputs — for string and version variables (OS Version, Language, App Version, Country, etc.). Type any value to simulate
- Number inputs — for numeric variables (Days Since Install, etc.)
As you change values, the canvas updates in real time — you can see exactly which styles are applied and how the screen looks for any combination of conditions.
Active Rules
The bottom section of the panel shows Active Rules — a live list of which rules are currently matching based on the current variable values. This makes it easy to verify that the right rules fire for the right conditions.
Try different combinations of variables to make sure your rules cover all the edge cases — for example, switching between iOS and Android while toggling dark mode, or selecting different products to verify the highlighting works correctly.
Common Use Cases
Highlight the selected product
Condition: Selected Product equals the product ID
Typography override: Bold font weight, accent color
Use case: Make the currently selected product’s title or price stand out visually.
Condition: Platform equals iOS / Android
Spacing or Size override: Adjust padding, margins, or dimensions
Use case: Account for platform-specific UI conventions (e.g., larger touch targets on Android).
Dark mode support
Condition: Theme equals dark
Typography + Background + Border override: Light text on dark background, adjusted border colors
Use case: Ensure your paywall looks great in both light and dark themes.
Show/hide elements by entitlements
Condition: Has Any Entitlement equals true
Appearance override: Visibility hidden
Use case: Hide the purchase button for users who already have an active subscription.
Free trial badge
Condition: Product Has Intro equals true AND Intro Type equals free_trial
Appearance + Typography override: Show a badge, change text color
Use case: Visually indicate which products offer a free trial.
First-time user experience
Condition: Is First Launch equals true
Any style override: Different layout, larger text, highlighted CTA
Use case: Show a more prominent onboarding experience for first-time users.
SDK Requirements
Conditional logic requires the following minimum SDK versions:
| Platform | Minimum Version |
|---|
| iOS | 6.8.0 |
| Android No-Codes SDK | 1.7.0 |
| Flutter | Coming soon |
| React Native | Coming soon |
| Unity | Coming soon |
| Cordova | Coming soon |
| Capacitor | Coming soon |
setContext event. If the SDK version is too old, conditional logic rules will still be present in the published HTML but the context will be empty — meaning no rules will match and default styles will be shown.
Limitations
- Conditional logic is available for Mobile Paywall and Mobile Onboarding screen types only
- Condition groups can be nested up to 2 levels deep
- Each group supports up to 10 conditions
- A soft warning appears when a style block has 20+ rules (no hard limit)
- Rules are evaluated client-side in the published HTML — complex rule sets may have a minor performance impact
- Screen variables are local to the screen and are not persisted across sessions
