Critical Moments Docs
Quick StartHomepageAccount
  • Documentation Home
  • What is Critical Moments?
  • Quick Start
  • Concepts Overview
  • Remote Control / Service
    • Host Config on Github Pages
  • Config File Structure
  • Demo App
  • Homepage & Account
  • 📚Guides
    • Mobile App Toolbox: 13 Features Most Apps Need
    • Reduce App Churn with Notifications
    • Improve your App Store Rating
    • Feature Flags Guide
  • ⏰Notifications
    • Intro to Notifications
    • Notifications Spec
    • Smart Delivery
    • Badges
  • 🎯Conditional Targeting
    • Intro to Conditions
    • Built-in Properties
    • Custom Properties
    • Syntax and Operators
    • Conditional Guides
      • Working with Dates
      • Locations and Weather
      • Event and Property History
  • 🎪Events
    • Event Overview
    • Recommended Events
    • Built-In Events
  • 💬Actions / In App Messaging
    • Actions Overview
    • Modals
      • Modal Content Sections
      • Modal Buttons
      • Modal Images
    • Banners
    • Alerts
    • App Reviews
    • Open Link
    • Custom Actions
    • Conditional Actions
    • Triggers
  • 🎨Themes
    • Theme Overview
    • Built In Themes
  • ⛳Feature Flags
    • Feature Flag Guide
    • Conditional Feature Flags
    • Named Conditions Config
  • 🔑Trustless SaaS
  • 👋Support
  • 👩‍💻SDK API Reference
Powered by GitBook
On this page
  • checkNamedCondition API
  • Remote updates
  • Advanced Usage

Was this helpful?

  1. Feature Flags

Conditional Feature Flags

How to use condition strings in code to enable or disable features

Last updated 9 months ago

Was this helpful?

Be sure to read our , which covers common Feature Flag implementations.

are great way to enable new features, stage rollouts, and disable features that are end of life.

However, static flags and randomized rollout often aren't powerful enough. What happens if you find out your new feature has a bug on iPad, issues on cellular networks, or bugs in some locales? What if you want to target only long standing users initially to prevent data from new users clouding the results of AB test?

You can't think of every condition you might need ahead of time, but with our conditional checks you can used advanced targeting, and update your targeting after you ship.

checkNamedCondition API

This API is simple, but powerful. It evaluates a condition string, and returns if it's true or false.

The condition strings are defined in your , allowing you to update them remotely without app updates.

Be sure to provide a unique name to each use case. Don't reuse names even if the current conditional logic is equivalent; that will make it impossible to override each usage independently from your remote config file.

// Optionally try/catch the for errors
let result = try? await CriticalMoments.shared().checkNamedCondition("userNotDistracted")
if result {
   // Perform action
}
[CriticalMoments.sharedInstance 
        checkNamedCondition:@"userNotDistracted" 
        handler:^(_Bool result, NSError * _Nullable error) {
    if (error != nil) {
        NSLog(@"Error: %@", error);
    } else if (result) {
        // Perform action
    }
}];

Parameters and Return Value

  • name: A name for this condition. Must be provided and can not be an empty string. This name is used to look up the conditional string from your .

  • error: Any errors returned from evaluating the condition.

Return Value

Returns the result of evaluating the condition. Always false for any error.

Remote updates

Advanced Usage

You can update your conditions anytime from the cloud. The config file format to do so is described .

See our for tips on how to implement staged rollouts, rollback, and other feature flag strategies.

⛳
Feature Flag Guide
Feature flags
config file
config file's named conditions
here
feature flag guide