Overview
This developer guide will assist you in configuring your iOS/macOS platform for Feature Flags using the Mixpanel Swift SDK. Feature Flags allow you to control the rollout of your features, conduct A/B testing, and manage application behavior without deploying new code. For complete Swift SDK documentation, see the Swift SDK guide.Prerequisites
Before implementing Feature Flags, ensure:- You are on an Enterprise subscription plan and have the latest version of the SDK installed (minimum supported version is
v5.1.3). If not, please follow this doc to install the SDK. - You have your Project Token from your Mixpanel Project Settings
Flag Initialization
Initializing the SDK with feature flags enabled requires passing aFeatureFlagOptions configuration to MixpanelOptions. This enables making an outbound request to Mixpanel servers with the current user context.
The server will assign the user context to a variant for each feature flag according to how they are configured in the Mixpanel UX.
The response will include an assigned variant for each flag that the user context is in a rollout group for. If a flag is not returned, it most likely signifies that the user was either not in the rollout percentage for a flag or in the configured targeting cohort.
Example Usage
distinct_id or device_id for any of the feature flags in your project, then the call to initialize feature flags must include those keys.
For example, for a Variant Assignment Key, company_id, you would setup the SDK as follows:
custom_properties node within the context:
Flag Persistence
Minimum supported SDK version:v6.4.0
By default (networkOnly), the SDK fetches fresh flag assignments and waits for the network response before variant calls complete. You can enable persistence to persist assignments to UserDefaults so they are available immediately on subsequent launches.
Configure a variantLookupPolicy on FeatureFlagOptions:
networkFirst — The SDK waits for the network on every launch. If the network call fails, the persisted value is returned as a fallback. Async getter calls block until the fetch completes (or the fallback is resolved).
persistenceUntilNetworkSuccess — Persisted variants are returned immediately on launch. Each getter call while serving persisted data triggers a background network fetch (deduplicated — only one fetch runs at a time). If the fetch fails, persisted data continues to be served and the next getter call retries the fetch. Once a fetch succeeds, the in-memory state updates and subsequent calls no longer trigger background fetches.
TimeInterval:
Variant source
EveryMixpanelFlagVariant carries a source property indicating where the value came from: .network, .persistence(persistedAt:), or .fallback. Use getVariant() to receive the full variant object.
$experiment_started properties
When a variant is served, the $experiment_started exposure event includes:
$variant_source—"network"or"persistence"$persisted_at_in_ms— epoch ms when the variant set was persisted (persistence only)$ttl_in_ms— the configured TTL in ms (persistence only)
Persisted variants are tied to the current
distinct_id. Calling identify() with a new ID or calling reset() clears persisted data and triggers a fresh fetch.Flag Reload
Following initialization, you can reload feature flag assignments in a couple of ways:- After a user logs in or out of your application and you call
identify, a feature flag reload will be triggered.
- To refresh flag variants that may have changed during the lifetime of your app, you can manually reload flags.
- To update the feature flags context after initialization and trigger a reload with the new values, use
setContext. This completely replaces the previously set custom context.
- Calling
reset()clears all feature flag assignments from memory and triggers a new fetch for the updateddistinct_id. Requires SDK versionv6.4.0or later.
Deferred Flag Loading
By default, feature flags are automatically fetched when the app first enters the foreground (prefetchFlags defaults to true). If your workflow requires calling identify() before the first flag fetch — for example, to ensure flags are evaluated against the correct user — you can defer automatic loading by setting prefetchFlags to false:
prefetchFlags is set to false, flags will not be loaded until you explicitly call identify() or Mixpanel.mainInstance().flags.loadFlags().
Flag Evaluation
Lookup the assigned value for a feature flag. This action triggers tracking an exposure event,$experiment_started to your Mixpanel project.
Asynchronous Flag Variant Retrieval
Experiment Flags: Get Variant ValueSynchronous Flag Variant Retrieval
Experiment Flags: Get Variant ValueGet All Flag Assignments
You can retrieve all feature flag assignments at once. These methods do not trigger$experiment_started tracking events.
Synchronous
getAllVariantsSync() returns a [String: MixpanelFlagVariant] dictionary containing all current flag assignments. If flags have not been loaded yet, it returns an empty dictionary.
getAllVariants(completion:) returns a [String: MixpanelFlagVariant] dictionary via a completion handler. If flags have not been loaded yet, it will attempt to fetch them before returning.
Frequently Asked Questions
What if I’m not receiving any flags on SDK initialization?
- Check your project token:
- Ensure you’re using the correct project token from your Mixpanel project settings
- Review flag configuration:
- Make sure your feature flag is enabled
- Check the flag’s rollout percentage
- User contexts that are not assigned to the rollout percentage will not receive flags
- If you are using a targeting cohort, verify on the mixpanel ‘Users’ page that the user’s
distinct_idis a member of that cohort.
- Review SDK parameters:
- Ensure
FeatureFlagOptions(enabled: true)is passed toMixpanelOptionsvia thefeatureFlagOptionsparameter - If using a custom Variant Assignment Key, ensure it is included in the
FeatureFlagOptionscontextparameter - If using Runtime Targeting, ensure all properties used in targeting are included in the
custom_propertiesobject within theFeatureFlagOptionscontext
- Check flags readiness: Use
areFlagsReady()to check if flags have been loaded before making synchronous calls - Enable debug mode: Set up logging to see detailed information about flag requests and responses