App Config

The App Config section (part of Remote Config) is designed to store and manage configuration settings for each application in the system.

It is used for:

Setting up the default configuration that is embedded into the app build;
Checking the current state of the configuration for different user types — such as new users, paying users, or users from specific countries;
Verifying A/B tests by retrieving configurations for different test groups to validate correct setup.

All parameters in this section are used to download the corresponding JSON config with specified user conditions and attributes. The actual config file is downloaded in Remote Config → App Version.

This tool helps configurators, marketers, product managers, and QA testers reproduce and verify application behavior across different scenarios — without developer involvement or changes to the app code or SDK.

General Information

A separate configuration card is created manually for each application. Each application has a single App Config card. It is reused and can be updated when needed — there is no need to create separate configuration cards for different app versions.

How to create a new App Config

Go to App Config.
Click Create New.
Fill in the required fields (see below).
Save the changes.

Settings Overview

Below is a description of the required and optional fields available for configuring application settings.

Application

The application for which this configuration is created.

This field can be selected only once when creating the App Config card for the first time.
After saving the configuration, the Application field becomes locked and cannot be edited.

Device

The device model used to generate the configuration. This parameter determines which device profile is applied when retrieving the JSON config, including screen size, resolution, and performance category.

This is a key field for testing configuration behavior on different device classes.

Examples

Android

Android devices are typically represented by generalized density categories rather than specific phone models. Examples:

phone-xxhdpi — common for mid-range devices
phone-xxxhdpi — high-density screens (flagship devices)
tablet-xhdpi — tablets with xhdpi density

These categories imitate the device classes most commonly used by your audience.

iOS

iOS devices are represented by specific device models. Examples:

iPhone12,3 (iPhone 11 Pro)
iPhone14,5 (iPhone 13)
iPhone15,2 (iPhone 14 Pro)
iPad8,9 (iPad Pro 11”)

Selecting an iOS device helps verify how the configuration behaves on a specific Apple device model.

General Recommendations

If your app primarily targets smartphones, choose a phone device type.
If your app has a dedicated tablet experience, choose a tablet device type.
For Android, use a widely adopted density class (e.g., phone-xxxhdpi) to simulate the most common user environment.
For iOS, choose a current, widely used iPhone model (e.g., iPhone 13 / 14).

Orientation

Specifies the screen orientation of the application for the selected device.

Available values:

portrait — the app operates in vertical orientation
landscape — the app operates in horizontal orientation
both — the app supports both orientations, and the configuration reflects a state not tied to a single orientation

This field is important for applications where UI elements, layout behavior, or feature availability differ depending on the device orientation.

OS Version

Specifies the operating system version for which the configuration should be generated.

This field helps reproduce configuration behavior on different OS versions, including cases where app features, SDK behavior, or system APIs differ between Android and iOS releases.

Initial App Version

Specifies the first app version that the user installed on their device.

This field is used to simulate behavior for users whose initial installation happened on a specific version. This matters because different versions of the app may include:

different onboarding flows, tutorials, or paywalls,
new or deprecated features,
version-based A/B tests,
changes in LiveOps logic,
different remote config rules tied to version ranges.

When this is useful

Validating transitions from old builds to new ones
Checking that new users on older versions receive correct config values
Testing behavior tied to the user’s first installed build
Ensuring new features only activate for users starting from specific versions

Is New User

Determines whether the user is considered new (first-time installer of the app).

By default, the value is set to false. This means the configuration is generated as if the user is an existing user.

If you set Is New User = true, the downloaded JSON configuration will represent the state intended only for new users of the specified app version.

This parameter is used to verify the logic and behavior that apply exclusively at the user’s first launch, including:

onboarding flow
initial promotional offers
welcome bonuses / welcome A/B tests
early-stage content availability
enabling or disabling features specifically for new users

Using this field allows you to reproduce the exact configuration a real user would receive on their first app launch, based on the selected conditions (country, version, device, etc.).

Language

Specifies the user’s language. This parameter is used when the application includes language-based logic or localized configuration settings.

Examples: English, French, German, Castilian Spanish, Japanese

How it works: When a language is selected, the system will generate a JSON configuration that reflects all language-specific rules, flags, or content variations defined in Remote Config.

Used for:

validating localized content and feature availability
ensuring correct fallback behavior when certain translations or localized settings are missing
testing configurations where language is used as a segmentation attribute

When to use:

to confirm that localized features activate correctly for a specific language
to ensure UI text, dynamic strings, or region-specific elements load properly
to reproduce configuration issues observed only on certain language settings

Country

Determines the user’s country. The value is selected as the full country name, for example:

United States
Canada
Germany
Brazil
Japan

This parameter is used to simulate how the application behaves in different regions. When a country is selected, the system generates a JSON configuration that includes all region-specific rules defined in Remote Config. If no specific rules exist for the chosen country, the fallback (default) configuration is applied.

Used for:

testing regional LiveOps campaigns;
enabling or disabling features for specific regions;
validating geography-based A/B tests;
checking localized parameter values;
troubleshooting issues that occur only in certain countries.

For downloading the default configuration, it is recommended to set:

Country = United States

Why:

most projects define their baseline configuration for the U.S. market;
this region typically has no special constraints or exceptions;
the U.S. configuration is often the most complete and stable, serving as the reference state;
most A/B tests and LiveOps campaigns start with the U.S. market, making it the most representative default environment.

Using United States ensures a predictable baseline configuration that closely reflects the default logic of the application.