Remote Control / Service

Remotely control your app's behaviour without App Store updates

The behaviour of the Critical Moments SDK is controlled by a powerful config file, which can be remotely updated from a server without app updates. Changing the SDK config unlocks a powerful set of features:

• Update the conditional targeting to optimize your revenue engine (eg: Subscription prompts)

• Update your user journey conditional targeting and messaging to improve user activation

• Update your app review prompt conditional targeting

• Push new user messaging for unexpected issues and announcements. Examples: outages, announcements, or legal compliance (new privacy policy, or EU data regulations)

• Updating which feature flags are on/off, including rolling out AB test segments, rolling back bugs, and targeting feature flags based on live-device conditions.

Who Hosts the Remote Config?

You do! You can host our config anywhere your company hosts files on the web.

Other feature flag and remote-messaging tools require learning new dashboards, adding new access controls, creating new review processes, and sometimes even hosting/monitoring new services. Critical Moments allows you to use your existing tools (Git, Github, your webserver, etc)!

We offer a guide for quickly setting up free hosting using Github Pages, which should work for companies at any scale.

Trustless: Security and SLA

Since you host the config file yourself, Critical Moments can't push updates to your config without your permission/consent.

Further: an outage of our service can't impact your users.

How to Host Your Config / Remote Updates

For local development you can use a local and unsigned JSON config file built into the app binary. However, production builds must use a signed config file, hosted on a web server you control.

You have several choices for how to sign and deploy your config file

• Manually: using our drag and drop tool to sign, then upload to the web host of your choice.

• Using Github: use Git for version control, Github Actions to sign, and Github Pages to deploy/host. This is a powerful option which enables permission/controls, collaboration, and automatic deployment. However, it requires a little setup. See our guide for details.

• Custom automated deployments (CD): integrate into the deployment toolchain of your choice.

Considerations if you want to use a host other than Github

If you want to use another host for your config, here are some best practices to consider:

• Choose a hosting provider that has robust access controls, to control who on your team can update this config. Since this config can push messaging to all your users, you want to keep this secure and limit updates to trusted team members.

• If using a custom domain name, use one you own, keep secure, and intend to keep owning for the lifetime of your application.

• Choose a hosting provider which supports the ETag header is best, and will reduce the amount of network traffic from your app. Almost all major hosts support this, including Github Pages, Amazon S3, Google GCP Cloud Storage, and Microsoft Azure.

• Choose hosting provider you already use, and is familiar to your dev/ops team

Once you pick a URL, update your code to point to it (in your app delegate's call to setReleaseConfigUrl, see the Quick Start guide). This must be done before you release to the app store.

Be sure to test everything works as desired before deploying a new config to your production host. Remember: if deploying to a config to a URL used by older app releases, ensure to not break them with new configs.

Trustless: Access Control

Each company has different ways of securing their services and granting employees access.

By self-hosting the config file, you can use your existing access control systems to match the way you already work, and comply with your internal security requirements.

Config File Signing

Your config file must be signed before deploying to your web server. You need to register your bundle ID in your account before signing a config.

The signing process will detect common issues with your JSON, and prompt you to fix them, giving an extra layer of error checking before deployment.

Typically you develop using cmDevConfig.json locally, then sign and deploy a matching signed config as part of your app release process. This process should be repeated whenever you update your config file (including outside the app release flow if desired).

If using our guide for hosting on Github Pages, signing and deployment will be automatic every time you update your config!

Manually Signing Config Files

If you aren't using our GitHub Action to sign your file, you can also manually sign a config file.

User Interface Tool

Our drag and drop tool will take your raw JSON config file and produce a signed cmconfig file which can be deployed to your web server.

Automated Signing: Custom Deployment Tooling

You can automate signing and deploying your config file.

See our signing shell script for an example of automating signing; then integrate it into the deployment system of your choosing.

The signing process is for Critical Moments to ensure the config file is valid before deployment (including that you use the features in your subscription level).

Signing is not a security mechanism controlling who can sign or update your config. Anyone can sign a config using the public signing tool. Be sure to use your hosting provider's access control for who can deploy your config as described in Hosting Best Practices.

The signing tool does not require sharing the Critical Moments Billing Portal credentials/password across your team.

Trustless: Validation

You can verify the config file's content hasn't changed during the signing process. Open the cmconfig file in any text editor, extract the CONFIG section, and decode the base64 content body.

The empty json file {} can be deployed without signing. This allows you to clear your config any time.

Trustless SaaS

Critical Moments is built as what we call "Trustless SaaS": software designed to be remotely controlled from services, without needing to trust a 3rd party service provider for correctness, security, or uptime SLAs.

Learn more about Trustless SaaS ->