This product is not supported for your selected Datadog site. ().
Cette page n'est pas encore disponible en français, sa traduction est en cours. Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.
Join the Preview!
Feature Flags are in Preview. Complete the form to request access.
This page describes how to instrument your iOS or tvOS application with the Datadog Feature Flags SDK. Datadog feature flags provide a unified way to remotely control feature availability in your app, experiment safely, and deliver new experiences with confidence.
This guide explains how to install and enable the SDK, create and use a FlagsClient, and configure advanced options.
Installation
Declare DatadogFlags as a dependency in your project. The recommended installation method is Swift Package Manager (SPM).
To install the Datadog Feature Flags SDK using Apple’s Swift Package Manager, add the following as a dependency to your Package.swift file:
Initialize Datadog as early as possible in your app lifecycle—typically in application(_:didFinishLaunchingWithOptions:) (or with @UIApplicationDelegateAdaptor for SwiftUI apps). This ensures all feature flag evaluations and telemetry are captured correctly.
If a client with the given name already exists, the existing instance is reused.
Set the evaluation context
Define who or what the flag evaluation applies to using a FlagsEvaluationContext. The evaluation context includes user or session information used to determine which flag variations should be returned. Call this method before evaluating flags to ensure proper targeting.
This method fetches flag assignments from the server asynchronously. By providing an optional completion callback or using the async/await variant you can handle the result of context evaluation:
do{tryawaitflagsClient.setEvaluationContext(evaluationContext)// Context set successfully}catch{print("Failed to set context: \(error)")}
Evaluate flags
After creating the FlagsClient and setting its evaluation context, you can start reading flag values throughout your app. Flag evaluation is local and instantaneous—the SDK uses locally cached data, so no network requests occur when evaluating flags. This makes evaluations safe to perform on the main thread.
Each flag is identified by a key (a unique string) and can be evaluated with a typed getter that returns a value of the expected type. If the flag doesn’t exist or cannot be evaluated, the SDK returns the provided default value.
Boolean flags
Use getBooleanValue(key:defaultValue:) for flags that represent on/off or true/false conditions. For example:
For numeric flags, use getIntegerValue(key:defaultValue:) or getDoubleValue(key:defaultValue:). These are appropriate when a feature depends on a numeric parameter such as a limit, percentage, or multiplier:
For structured or JSON-like data, use getObjectValue(key:defaultValue:). This method returns an AnyValue, which can represent primitives, arrays, or dictionaries. Object flags are useful for remote configuration scenarios where multiple properties need to be provided together. For example:
When you need more than just the flag value, use the get<Type>Details APIs. These methods return both the evaluated value and metadata explaining the evaluation:
letdetails=flags.getStringDetails(key:"paywall.layout",defaultValue:"control")print(details.value)// Evaluated value (for example: "A", "B", or "control")print(details.variant)// Variant name, if applicableprint(details.reason)// Description of why this value was chosen (for example: "TARGETING_MATCH" or "DEFAULT")print(details.error)// The error that occurred during evaluation, if any
Flag details may help you debug evaluation behavior and understand why a user received a given value.
Advanced configuration
The Flags.enable() API accepts optional configuration with options listed below.
When true (default), the SDK automatically records an exposure event when a flag is evaluated. These events contain metadata about which flag was accessed, which variant was served, and under what context. They are sent to Datadog so you can later analyze feature adoption. If you only need local evaluation without telemetry, you can disable this option.
rumIntegrationEnabled
When true (default), flag evaluations are tracked in RUM, which enables correlating them with user sessions. This enables analytics such as “Do users in variant B experience more errors?”. If your app does not use RUM, this flag has no effect and can be safely left at its default value.
gracefulModeEnabled
Controls how the SDK handles incorrect use of the FlagsClient API—for example, creating a client before calling Flags.enable(), creating a duplicate client with the same name, or retrieving a client that hasn’t been created yet.
The exact behavior of Graceful Mode depends on your build configuration:
Release builds: The SDK always enforces Graceful Mode: any misuse is only logged internally if Datadog.verbosityLevel is configured.
Debug builds with gracefulModeEnabled = true (default): The SDK always logs warnings to the console.
Debug builds with gracefulModeEnabled = false: The SDK raises fatalError for incorrect API usage, enforcing a fail-fast approach that helps detect configuration mistakes early.
You can adjust gracefulModeEnabled depending on your development or QA phase.
customFlagsEndpoint
Configures a custom server URL for retrieving flag assignments.
customExposureEndpoint
Configures a custom server URL for sending flags exposure data.
customFlagsHeaders
Sets additional HTTP headers to attach to requests made to customFlagsEndpoint. It can be useful for authentication or routing when using your own flags service.
Further reading
Documentation, liens et articles supplémentaires utiles: