Remote Control / Service
Remotely control your app's behaviour without App Store updates
Last updated
Remotely control your app's behaviour without App Store updates
Last updated
The behaviour of the Critical Moments SDK is controlled by a powerful , 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.
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 , 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.
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
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.
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).
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).
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.
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.
Manually: using our to sign, then upload to the web host of your choice.
Using : 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 .
(CD): integrate into the deployment toolchain of your choice.
Choose a hosting provider which supports the 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.
Once you pick a URL, update your code to point to it (in your app delegate's call to setReleaseConfigUrl, see the guide). This must be done before you release to the app store.
Your config file must be signed before deploying to your web server. You need to register your bundle ID in your before signing a config.
If using our guide for , signing and deployment will be automatic every time you update your config!
Our will take your raw JSON config file and produce a signed cmconfig file which can be deployed to your web server.
See our for an example of automating signing; then integrate it into the deployment system of your choosing.
Signing is not a security mechanism controlling who can sign or update your config. Anyone can sign a config using the . Be sure to use your hosting provider's access control for who can deploy your config as described in .
The signing tool does not require sharing the credentials/password across your team.