App Version: Configuration Download and Usage

Overview

The App Version section is used to manage application versions and retrieve configuration files generated based on App Config settings.

It allows you to download the configuration that the application uses for a specific app version in different states — from the baseline configuration embedded into the build to the current configuration resolved with segmentation and additional user conditions.

Purpose of App Version

The App Version section serves two primary purposes:

1. Application version management

Each application version is registered in the system and used as an independent context when resolving configuration logic.

App versions are used through Segmentation — to define rules that apply only to specific app versions or version ranges.

Segments are applied across multiple system entities, including campaigns, features, experiments, and configuration resolution logic.

In addition, app versions are used in LTO campaign settings, where campaign behavior may depend on the application version.

2. Configuration retrieval for a specific version

The App Version section allows you to download JSON configuration files calculated for a selected application version and execution context.

How App Versions Appear in the System

App versions are created and managed inside the application card and can appear in the system either automatically or manually.

When a version is created, the following attributes are defined:

• version number;
• publication date (Published At);
• verification status (Is Verified).

Automatic Version Creation

A new version is created automatically when the application sends a configuration request with a version number that does not yet exist in the system.

This usually happens when a new build is launched and makes its first request to the backend.

In this case:

• the version is created automatically;
• Published At is set to the version creation date;
• the version is created without Is Verified and is considered unverified.

Manual Version Creation

App versions can also be added manually in advance, before a new release goes live.

This is recommended when you want to prepare configuration, segmentation, or analytics ahead of the rollout.

Versions are created in:

Configuration > Remote Config > Application

How to add a version manually

1. Open the application card.
2. Go to the versions list.
3. Click + Add Version.
4. Enter the version number and save the changes.

After saving:

• the version becomes available in the system;
• Published At is filled with the creation date;
• the version remains unverified until the release is confirmed.

Version Verification (Is Verified)

Is Verified indicates that the application version has been released to real users.

Version verification is performed in the same application card where versions are managed.

How to verify a version

1. Open Configuration > Remote Config > Application.
2. Locate the required version in the versions list.
3. If needed, update Published At to match the actual store release date.
4. Enable the Is Verified checkbox next to the version.

After verification:

• the version is treated as released in production;
• it is considered an active production version by the system;
• its status and publication date are used in analytics and reports.

Example dashboard with a dashed line indicating the app version release date

Hovering over the dashed line displays the application version number

Managing Versions in App Version

The App Version section displays all registered application versions and provides tools to work with them.

You can:

• filter versions by application;
• search for a version by number;
• customize visible table columns;
• sort versions by application or version name.

Each table row represents a specific app version and provides actions for downloading configuration files related to that version.

Column titles such as Get Default, Get Current, and Get Config with custom parameters indicate the available configuration types.

To start a download, click the highlighted configuration name (for example, Default config) inside the corresponding column.

Clicking the configuration name triggers generation and download of the configuration file in JSON format.

Configuration Types in App Version

For each app version, the following configuration types are available:

• Get Default config: download Default config
• Get Default (sandbox) config: download Default (sandbox) config
• Get Current config: download Current config
• Get Current (sandbox) config: download Current (sandbox) config
• Get Config with custom parameters: download Current config
• Get Config with custom parameters (sandbox): download Current (sandbox) config

Each type represents a distinct way of resolving and downloading a configuration file for the selected app version.

Default Config

Default config is the baseline configuration embedded into the application build for the selected app version.

Default (sandbox) config is the same baseline configuration, generated using sandbox data.

Purpose

• Ensures a predictable startup state of the application (for example, on first launch without internet connectivity).
• Used as the configuration embedded into the build before the first successful server request.
• Defines the base configuration on top of which Remote Config and segmentation rules are applied.

Current Config

Current config is the active configuration delivered to the application from the server when internet connectivity is available.

Current (sandbox) config is the same configuration calculated using sandbox data.

Purpose

• Inspect the configuration currently delivered to users.
• Validate changes in Remote Config rules, segmentation, campaigns, features, and experiments without releasing a new app version.
• Safely test configuration logic using sandbox data.

Key Logic

• Current configurations include all active rules: segmentation, campaigns, features, and experiments.
• The baseline context is taken from the main App Config block.

• The only difference between production and sandbox is the data source.

Config with Custom Parameters

Get Config with custom parameters is a separate configuration type used to validate a specific user scenario.

It is resolved using current configuration logic but with an extended user context.

Variants

• Get Config with custom parameters — production data
• Get Config with custom parameters (sandbox) — sandbox data

Custom Parameters

May include:

• Days After Launch
• Days of Week
• IDFA
• In-App Purchases (revenue / count)
• Rewarded Video Impressions
• UA fields (Media Source / Campaign / Ad Group)
• Products
• A/B test parameters

Purpose

• QA and debugging: “What configuration does a user with condition X receive under scenario Y?”
• Validation of A/B tests and narrow segmentation rules.
• Reproducing real-user cases without impacting production.

Relationship Between App Version and App Config

App Config defines the context from which all configurations are resolved.

• The main App Config block defines the baseline context (device, OS, country, language, etc.) > used for Default config and Current config.
• Additional parameters are applied when a more specific user scenario is required > used in Get Config with custom parameters.

Configuration Application Logic in the App

The application always uses the last successfully fetched current config.

How it works

1. The app requests the current config.
2. If the config is successfully fetched and valid:
   • it is applied;
   • saved locally;
   • used for subsequent launches.
3. If a subsequent request fails or returns an invalid config:
   • the app continues using the last working current config.

Configuration Validation

After downloading a configuration, it is recommended to inspect its structure and contents.

You can use any convenient JSON tool, for example:

• Online JSON Viewer and Formatter
• JSON Online Viewer
• JSON Editor Online

Or any other tool suitable for viewing and analyzing JSON files.

Configuration validation is especially useful for QA, debugging, and analyzing configs generated with custom parameters.