Test and Launch

Test Remote Config like production code. The app will read a resolved value by key, so the safest launch path is to make the server value easy to isolate and the client fallback easy to verify.

​

1. Start with a QA-safe surface

Use one of these patterns before broad rollout: AppActor does not currently expose a public SDK method for manually pinning one user to one Remote Config. Do not document or ship forced-user code for Remote Config testing.

​

2. Verify the SDK read path

For every key the app depends on, verify:

• Fresh fetch returns the expected value.
• Typed getters return null or nil when the type does not match.
• Missing keys fall back to local app defaults.
• JSON payloads are schema-checked before rendering.
• Purchase and entitlement flows still use customer info.

​

3. Test cold start and cache behavior

Remote Config can load from memory or disk cache depending on platform and timing. Test:

• first install with no cache
• second launch with cached config
• offline or transient network failure after a successful fetch
• user identity changes if rules depend on entitlement state
• app version changes when rules target version ranges

​

4. Launch gradually

Prefer this order for risky UI or purchase-surface changes:

1. App-scoped QA config.
2. Narrow version or country rule.
3. Broader platform rule.
4. Project-wide default after the payload is stable.

​

5. Roll back

The fastest rollback is usually one of:

• deactivate the risky config
• deactivate the risky rule
• move the default value back to the previous production payload
• lower traffic by moving the behavior into an experiment instead

​

Next