App Version: Configuration Download and Usage

This article provides a detailed reference for the App Version section. It explains how application versions are managed in the system and how different types of configurations are generated and downloaded for a specific app version.

The following sections describe:

• how app versions appear in the system;
• how versions are managed and displayed in App Version;
• the available configuration types and their purpose;
• how configuration download relates to App Config settings.

Role of App Versions in the System

An application version represents a specific build of the app and is treated as an independent context when resolving configuration logic.

App versions are used across multiple system areas:

• Segmentation — to define rules that apply only to specific app versions or version ranges;
• Campaigns — to control campaign behavior that may differ between app versions;
• App Version — to download configurations generated for a particular version of the app.

Each version acts as a reference point that determines which configuration the application would receive at runtime.

How App Versions Appear in the System

App versions can appear in the system in two ways: automatically or manually.

Automatic creation A new version is created automatically when the application sends a configuration request with a version 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.

Manual creation App versions can also be added manually in advance, before a new release goes live. This is done in the Application section and is recommended when you want to prepare configuration, segmentation, or reporting ahead of the rollout.

To add an app version manually:

1. Open the Application section.
2. Select the required application.
3. Open the Versions subsection.
4. Click + Add Versions.
5. Enter the version number and save the changes.

Once saved, the version becomes available across the system, including the App Version section.

Managing and Viewing Versions in App Version

The App Version section displays all registered versions of applications and provides tools to filter, sort, and manage them.

You can:

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

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

Configuration Types Available in App Version

For each app version, App Version allows you to download several types of configurations. These configurations represent different runtime states of the application.

The available configuration types are:

• Get default config
• Get current config
• Get config with custom parameters

Each type serves a distinct purpose and is described in detail in the following sections.

Get Default Config

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

Purpose

• Ensures a correct and predictable startup state of the application (for example, when there is no internet connection on the first launch).
• Defines the base configuration on top of which Remote Config rules and segmentation are later applied when the current config is fetched.

Get Current Config

Current config is the active configuration that the application receives from the server when internet connectivity is available. It can be updated dynamically without releasing a new app version.

Purpose in App Version

• To verify what configuration is currently delivered to users under the selected baseline context.
• To validate changes in Remote Config rules, segmentation, and active campaigns without rebuilding the app.

Key Logic

• The current config reflects all active rules: segmentation, campaigns, feature flags, and experiments.
• The baseline context (such as country, language, device, OS version) is taken from the main App Config block.

Get Config with Custom Parameters

This configuration type is used when you need to validate a specific user scenario, not just a general baseline state.

It allows you to generate a configuration that includes:

• the baseline context (main App Config block);
• additional custom user parameters, such as:
  • 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 Configuration

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.

How Configuration Downloads Relate to App Config

App Config defines the context from which configurations are resolved.

• The main App Config block defines the baseline context (device, OS, country, language, etc.). → Used for both default config and current config.
• Additional parameters are applied when a more specific user scenario is required. → Primarily used for current config with custom parameters.

Version Fields

Each application version has a set of metadata fields that affect reporting, visualization, and interpretation of configuration behavior.

Published At

Published At defines the date when the application version was released to users.

How it works:

• When a version is added manually, the field is automatically filled with the date the version was created in the system.
• After the version is actually released to the store, this value should be updated to the real rollout date.

Why this field is important:

• It is used in reports and dashboards to determine when a specific app version started being used by real users.
• Correct publication dates ensure accurate analytics, cohort analysis, and version-based comparisons.
• If the date is incorrect, reporting data related to the version may be misleading.

Best practice:

• Always update Published At to match the actual release date in the store once the version goes live.

Is Verified

Is Verified indicates whether the app version has been confirmed as released to real users.

How it works:

• When enabled, the version is treated as verified and is considered active in production.
• Verified versions are visually marked in analytics and dashboards.

Impact on reporting:

• In dashboards and charts, a dashed vertical line is displayed at the publication date of a verified version.
• Hovering over this line shows the version number.
• This helps correlate changes in metrics with the release of a specific app version.

Use cases:

• Tracking performance changes after a new version rollout.
• Comparing metrics before and after a release.
• Visual validation of version impact on KPIs.

Best practice:

• Enable Is Verified only after the version has been released to users.
• Do not verify test or internal-only versions unless they are intentionally included in reporting.

Summary

• Published At defines when the version started rolling out.
• Is Verified defines whether the version should be treated as live and visible in reports.
• Together, these fields ensure correct interpretation of version-related analytics and configuration behavior.