Live Configuration Rules

Guide the app without waiting for a new build

Live configuration lets you adjust supported app settings for one Network after the app has been installed. The app requests its configuration when it starts and receives the settings that match its release channel, platform, version, and build.

Use rules for measured changes such as enabling a client feature or adjusting a supported limit. They do not replace server permissions, Network branding, subscription entitlements, or an app package release.

How the final configuration is built

1. Astarium begins with the platform defaults.
2. It finds active rules for this Network and release channel.
3. It keeps rules that match the requested platform, version, and build.
4. It applies matching rules from the lowest priority number to the highest.
5. It adds authoritative Network data, entitlements, catalogs, and the latest package details.

When two matching rules contain the same setting, the rule applied later wins. Give overlapping rules different priority numbers so that this order stays clear.

What each field means

Rule name

A clear internal description. It is not shown in the app.

Release channel

Production is the public app, Staging supports release checks, and Development supports active development. A rule only matches its chosen channel.

Platform

Choose iOS, Android, or every platform. A platform-specific rule can refine a broader rule.

Minimum and maximum version

Optional inclusive app-version boundaries, compared as version numbers such as 1.4.0. Leave both empty to match every version.

Minimum and maximum build

Optional inclusive build-number boundaries. Use these when store builds share a public version but need different behaviour.

Priority

Rules are applied from lower numbers to higher numbers. A higher number overrides matching keys from a lower number.

Settings

A JSON object containing only the settings this rule should change.

Apply this rule

Turn this off to keep the rule for later without sending it to apps.

Write focused settings

Objects merge with the defaults and earlier matching rules. Include only the keys you intend to change.

{
  "features": {
    "soundFx": false
  },
  "chat": {
    "messageLockAfter": 90
  }
}

The settings must be valid JSON with a named outer object. Use double quotes, do not add comments, and avoid copying the complete response into a rule. Catalogs, membership limits, Network terminology, and package metadata are generated by Astarium and may replace values supplied in a rule.

Plan overlapping rules

A simple priority pattern makes intent easy to follow:

• 10 — broad defaults for a release channel
• 20 — platform refinement
• 30 — version or build rollout
• 40 — short-lived corrective override

For example, a production rule at priority 10 can enable a feature for every platform. An iOS build rule at priority 30 can then pause that feature for a specific range while Android keeps the broader value.

Release changes calmly

1. Create the narrowest rule that expresses the change.
2. Begin with Development or Staging when the app supports that channel.
3. Confirm the JSON, target platform, and inclusive version or build boundaries.
4. Move the rule to Production or create a matching Production rule.
5. Watch the intended app versions, then pause or remove temporary rules when they are no longer useful.

Apps should send their platform, version, and build with every configuration request. If version or build metadata is omitted, Astarium cannot use that boundary to exclude the request. Configuration responses use an ETag, so apps can revalidate efficiently and receive the new configuration when the effective result changes.