4.28.0. See the Swift SDK changelog for release notes, or the SDK changelog index for all SDKs.
SDK methods: For the full reference documentation of the iOS SDK methods, see the reference section.
Developer guide
Follow these steps to install and configure the Kameleoon iOS SDK in your app for the first time.Getting started
Starter kit
To help with getting started, Kameleoon provides a starter kit and demo app to test the SDK. The starter kit includes a fully configured app with examples that demonstrate how to use SDK methods in an app. The starter kit, demo app, and detailed instructions are available at Starter kit for iOSPrerequisites
- Use Swift version 5.0 or higher on the iOS platform. Support for earlier iOS applications (including earlier Swift versions and Objective-C apps) isn’t planned. A Universal Framework version is available, compatible both with x86_64 (for the iOS Simulator) and ARM (for production deployment into the App Store).
Installation
You can install the iOS SDK using Swift Package Manager. Installation using CocoaPods is deprecated:- Swift Package Manager
- CocoaPods (deprecated)
With Swift Package Manager, add a package dependency to your Xcode project. Select File > Swift Packages > Add Package Dependency and enter the repository URL:
https://github.com/Kameleoon/client-swift.Alternatively, you can modify your Package.swift file directly:Additional configuration
To customize the SDK’s behavior, create akameleoon-client-swift.plist configuration file in the root directory of your Xcode project. You can also download a sample configuration file.
These are the keys you can set:
If you specify a
visitorCode and set the isUniqueIdentifier parameter to true, the SDK methods use the visitorCode value as the unique visitor identifier, which is useful for cross-device experimentation. The SDK links the flushed data to the visitor that’s associated with the specified identifier.The isUniqueIdentifier can be useful in other edge-case scenarios, such as when you can’t access the anonymous visitorCode that was originally assigned to the visitor, but you have access to an internal ID that’s connected to the anonymous visitor through session merging.Using activityTrackingIntervalMillisecond
The activityTrackingIntervalMillisecond parameter controls how often the SDK sends an activity event to extend the visitor’s session on the Data API. A longer interval reduces network usage and battery consumption. The default and minimum value is 60 000 ms (60 seconds); any lower non-zero value is ignored and the default is applied instead. Timers pause while the app is in the background, so the interval only advances while the app is in the foreground.
Increasing this value has significant side effects you should weigh carefully:
-
Visits with zero duration
- Reports derive visit duration from tracked events. If the interval is longer than the time a visitor spends in the app, the SDK may send only the startup event. The visit’s start and last-activity timestamps are then (nearly) identical, so the report usually shows a duration close to zero. You can avoid this by sending other events during the session (such as conversions or page views), which also extend the recorded duration.
-
Time elapsed since last visit (targeting)
- The “time elapsed since last visit” condition compares the current time against a previous visit’s last recorded activity. That timestamp only refreshes once per interval, so its precision degrades as the interval grows: comparisons for durations close to or below the interval become unreliable.
-
Visit count
- A new visit starts after 30 minutes of inactivity. If you set the interval longer than 30 minutes, every activity event arrives after the previous session has already expired, so the SDK creates a new visit at each interval and inflates the visit count.
Initialize the Kameleoon client
After you’ve set up the SDK in your app, you must create the Kameleoon Client. A Client is a singleton object that acts as a bridge between your app and the Kameleoon platform. It includes all the methods and properties you need to run an experiment.KameleoonClientFactory.create(), the client starts initialization but isn’t immediately ready for use. The client must retrieve the current experiment and feature flag configuration, including traffic allocation, from a Kameleoon remote server. This requires network access, which isn’t always available. Until the Kameleoon Client is ready, you shouldn’t run SDK methods that depend on experiment or feature flag configuration. After the first configuration is fetched, the client refreshes it periodically. If a later refresh fails, the Kameleoon client continues to use the previous configuration.
You can use the .ready property to check whether the Kameleoon client initialization is complete.
Alternatively, a helper callback can wrap the logic for triggering experiments and applying variations. The best approach (.ready or callback) depends on the use case. Use .ready when the SDK is expected to be ready soon, such as for an experiment in a dialog that users are unlikely to open during the first few seconds or minutes of app navigation. Use a callback when the SDK is likely to still be initializing, such as for an experiment shown at app launch.
It’s your responsibility as the app developer to ensure the client is ready before calling any methods. A good practice is to always assume that the app user should be left out of the experiment if the Kameleoon client isn’t yet ready. This exclusion is easy to do, as it corresponds to the implementation of the default reference variation logic as shown in the code sample preceding.
Best practices for initialization and usage
- Initializing
KameleoonClientas a singleton as early as possible after the app starts is recommended, as initialization may take some time. Since initialization is asynchronous, it doesn’t block or delay the app startup process. - Before using
KameleoonClient, verify that it’s initialized by calling therunWhenReadymethod. Otherwise, attempts to use the client before it’s ready will result in errors. - ⚠️ Most key methods may throw errors, so proper exception handling is required. Be sure to review the documentation for each method you use to understand its potential errors.
- Swift
- Swift (Async)
Activating a feature flag
Retrieving a flag configuration
To implement a feature flag in your code, you must first create the feature flag in your Kameleoon account. To determine the status or variation of a feature flag for a specific user, you should use thegetVariation() or isFeatureActive() method to retrieve the configuration based on the featureKey.
The getVariation() method handles both simple feature flags with ON/OFF states and more complex flags with multiple variations. The method retrieves the appropriate variation for the user by checking the feature rules, assigning the variation, and returning it based on the featureKey and visitorCode.
You can use the isFeatureActive() method to retrieve the configuration of a simple feature flag that has only an ON or OFF state, as opposed to more complex feature flags with multiple variations or targeting options.
If your feature flag has associated variables (such as specific behaviors tied to each variation) getVariation() also enables you to access the Variation object, which provides details about the assigned variation and its associated experiment. This method checks whether the feature flag targets the user, finds the visitor’s assigned variation, and saves it to storage. When track=true, the SDK sends the exposure event to the specified experiment on the next tracking request, which it triggers automatically based on the SDK’s tracking_interval_millisecond. The default interval is 1000 milliseconds (1 second).
The getVariation() method allows you to control whether the SDK tracks the visitor. If track=false, the SDK sends no exposure events. This option is useful if you prefer not to track data through the SDK and instead rely on client-side tracking managed by the Kameleoon engine, for example. Additionally, setting track=false is helpful when using the getVariations() method, where you might only need the variations for all flags without triggering any tracking events. If you want to know more about how tracking works, view this article
Adding data points to target a user or filter / breakdown visits in reports
To target a user, ensure you’ve added relevant data points to their profile before retrieving the feature variation or checking if the flag is active. Use theaddData() method to add these data points to the user’s profile.
To retrieve data points collected on other devices, use the getRemoteVisitorData() method. This method asynchronously fetches data from the servers. It’s important to call getRemoteVisitorData() before retrieving the variation or checking if the feature flag is active, because the SDK might need this data to assign a user to a given variation.
To learn more about available targeting conditions, see the detailed article on the subject.
Additionally, the data points you add to the visitor profile will be available when analyzing your experiments, allowing you to filter and break down your results by factors like device. See the complete list here.
If you need to track additional data points beyond what’s automatically collected, you can use Kameleoon’s Custom Data feature. Custom Data allows you to capture and analyze specific information relevant to your experiments. Don’t forget to call the flush() method to send the collected data to Kameleoon servers for analysis.
Tracking goal conversions
When a user completes a desired action (such as making a purchase), it’s recorded as a conversion. To track conversions, use thetrackConversion() method and provide the required goalId parameter.
The SDK sends the conversion tracking request along with the next scheduled tracking request, which occurs at regular intervals (defined by tracking_interval_millisecond). If you prefer to send the request immediately, use the flush() method with the parameter instant=true.
Cross-device experimentation
To support visitors who access an app from multiple devices, Kameleoon allows the synchronization of previously collected visitor data across each of the visitor’s devices and reconciliation of their visit history across devices through cross-device experimentation. Case studies and detailed information on how Kameleoon handles data across devices are available in the article on cross-device experimentation.Synchronizing custom data across devices
Although custom mapping synchronization aligns visitor data across devices, it’s not always necessary. Below are two scenarios where custom mapping sync isn’t required: Same user ID across devices If you use the same user ID consistently across all devices, the SDK handles synchronization automatically without a custom mapping sync. It’s enough to call thegetRemoteVisitorData() method when you want to sync the data collected between multiple devices.
Multi-server instances with consistent IDs
In complex setups involving multiple servers (for example, distributed server instances), where the same user ID is available across servers, synchronization between servers (with getRemoteVisitorData()) is sufficient without additional custom mapping sync.
Customers who need additional data can refer to the getRemoteVisitorData() method description for further guidance. In the below code, it’s assumed that you use the same unique identifier (in this case, the visitorCode, also known as userId) consistently between the two devices for accurate data retrieval.
If you want to sync collected data in real time, you need to choose the scope Visitor for your custom data.
- Swift
- Swift (Async)
Device A
Device B
Using custom data for session merging
Cross-device experimentation allows for combining a visitor’s history across each of their devices (history reconciliation). History reconciliation allows merging different visitor sessions into one. To reconcile visit history, useCustomData to provide a unique identifier for the visitor. For more information, see the dedicated documentation.
After you enable cross-device reconciliation, calling getRemoteVisitorData() with the parameter userId retrieves all known data for a given user.
Sessions with the same identifier always see the same variation in an experiment. In the Visitor view of your experiment’s results pages, these sessions will appear as a single visitor.
The SDK configuration ensures that associated sessions always see the same variation of the experiment. However, there are some limitations regarding cross-device variation allocation. The cross-device experimentation documentation outlines these limitations.
Follow the activating cross-device history reconciliation guide to set up your custom data on the Kameleoon platform.
Afterwards, you can use the SDK normally. The following methods that may be helpful in the context of session merging:
getRemoteVisitorData()with passedisUniqueIdentifier=truetoKameleoonClientConfig- to retrieve data for all linked visitors.trackConversion()orflush()with passedisUniqueIdentifier=truetoKameleoonClientConfig- to track some data for specific visitor that is associated with another visitor.
- Swift
- Swift (Async)
getVisitorCode() method. After the user logs in, the app associates the anonymous visitor with the user ID and uses it as a unique identifier for the visitor.
Using a custom bucketing key
By default, Kameleoon uses a unique, anonymous visitor ID (visitorCode) to assign users to feature flag variations. This ID is typically generated and stored on the user’s device (in a browser cookie for client-side and server-side SDKs, and in persistent storage for mobile SDKs). However, in certain scenarios you may need to ensure all users of the same organization see the same variant of a feature flag.
The Custom Bucketing Key option allows you to override this default behavior by providing your own custom identifier for bucketing. This override ensures that Kameleoon’s assignment logic uses your specified key instead of the default visitorCode.
Use cases
Using a custom bucketing key is essential for maintaining consistency and accuracy in your feature flag assignments, particularly in these situations:- Account-level or organizational experiments: For B2B products or scenarios where you want to assign all users from the same organization to the same variation, you can use an identifier like an
accountId. Custom bucketing keys are crucial for A/B testing features that impact an entire team or company.
Technical details
When you configure a custom bucketing key for a feature flag, you provide Kameleoon with a specific identifier from your app’s data:- Providing the custom key: You provide your custom identifier to the Kameleoon SDK using the
addData()method. In this method, you will pass your chosen custom bucketing key as aCustomDataobject. Here,newVisitorCoderefers to the identifier you wish to use for your bucketing (for example, the newuserIdoraccountId).
- Bucketing logic: Once you provide a custom bucketing key through the
addData()method, all hash calculations for assigning users to variations use thisnewVisitorCode(your custom key) instead of the defaultvisitorCode. Using thenewVisitorCodemeans that the bucketing decision depends on your custom identifier, ensuring consistent assignments across various contexts where that identifier is present. - Data tracking and analytics: It’s crucial to note that while the
newVisitorCode(your custom key) is used for bucketing decisions, the SDK sends all subsequent data (tracking events and conversions, for example) and associates it with the originalvisitorCode. This separation ensures that your analytics accurately reflect individual user journeys and interactions within your experiment’s broader context, even when you bucket at a higher level (like an account) or across multiple devices/sessions. Your original visitor data remains intact for comprehensive reporting.
Technical requirements
To effectively use a custom bucketing key:- The key must be a
String. - It must be unique for the entity you intend to bucket (for example, if using a
userId, each user’s ID should be unique). - The key must be available to the SDK at the exact moment it evaluates the feature flag decision for that user or request.
Targeting conditions
The Kameleoon SDKs support a variety of predefined targeting conditions that you can use to target users in your campaigns. For the list of conditions this SDK supports, see use visit history to target users. You can also use your own external data to target users.Error handling
The SDK throws its errors as two separate Swift types, so a single handler can’t catch every SDK failure:KameleoonError is an enum of the general SDK errors, and KameleoonError.Feature is a separate enum of the feature flag evaluation errors. KameleoonError.Feature is nested in the KameleoonError namespace but isn’t a case of it: a value of KameleoonError.Feature doesn’t cast to KameleoonError, so handle both types. Both conform to LocalizedError, so errorDescription gives you a readable message. Match a single case to react to a specific failure, for example to fall back to your default behavior when a feature flag isn’t in the configuration or the SDK isn’t initialized yet, or cast to the enum type to handle a whole group. The reference section of each method lists the errors it can throw.
SDK errors are expected behavior, not crashes: a feature flag that isn’t activated yet, an SDK that is still loading its configuration, or a network failure are all normal conditions. When feature evaluation fails, log the error and fall back to your default behavior so the visitor still gets a working experience.
Logging
The SDK generates logs to reflect various internal processes and issues.Log levels
The SDK supports configuring limiting logging by a log level.Custom handling of logs
The SDK writes its logs to the console output by default. This behaviour can be overridden.The SDK limits logging by log level separately from the log handling logic.
Passing the visitor code to a WebView
In some cases, you may need to pass the visitor code from the native app to a WebView that uses Engine.js or the web JavaScript or React SDKs. The following example demonstrates the recommended way to achieve this:- SwiftUI
- SwiftUI (iOS 26+)
Apple privacy compliance
Starting May 1, 2024, Apple requires apps that include a third-party SDK, such as the Kameleoon iOS SDK, that include a privacy manifest file. The latest version of the SDK is code-signed, compliant, and includes a valid manifest file with the SDK. No action is required if you’re using the Kameleoon iOS SDK version 4.2 or later.Reference
This is the full reference documentation for the Kameleoon iOS (Swift) SDK.Initialization
Once you have installed the SDK in your app, you must initialize Kameleoon. All of your app’s interactions with the SDK, such as triggering an experiment, are accomplished using this Kameleoon client object.create()
Call this method before any others to initialize the SDK. This method is inKameleoonClientFactory. create() creates an instance of KameleoonClient to manage all interactions between the SDK and your app.
You can customize the SDK’s behavior (for example, the environment, the credentials) by providing a configuration object. Otherwise, the SDK tries to find your configuration file and will use it instead.
Parameters
Return value
Exceptions thrown
ready
For mobile SDKs, the Kameleoon Client’s initialization isn’t immediate because it must retrieve the current configuration for active experiments and feature flags from a Kameleoon remote server. Read theready property before triggering an experiment to check whether the SDK is ready. Alternatively, you can use runWhenReady() with a callback.
Return value
runWhenReady()
- 🔄 Performs an asynchronous request (if the configuration is outdated or missing)
KameleoonClient can’t initialize immediately, as it needs to perform a server call to retrieve the current configuration for all feature flags. Use the runWhenReady() method to wait until the client is ready for use. Additionally, you can set a maximum timeout period to control how long the client will wait before it becomes ready.
If ready is true, the KameleoonClient is fully initialized, and feature flags will be evaluated and assigned their respective variations. If the result is false or a timeout occurs, the initialization won’t complete.
The callback or asynchronous code should handle applying the reference variation, as a timeout will exclude the user from the feature flag.
- Swift
- Swift (Async)
Arguments
Feature flags and variations
isFeatureActive()
- 📨 Sends Tracking Data to Kameleoon (depending on the
trackparameter)
This method was previously called
activateFeature, which was removed in SDK version 4.0.0.isFeatureActive() accepts featureKey as a required argument to check if the specified feature will be active for a visitor.
If a visitor has never been associated with this feature flag, this method returns a random boolean value (true if the user should be shown this feature, otherwise false). If the visitor is already registered with this feature flag, the method returns the previous featureFlag value.
Ensure you implement error handling as shown in the example code to catch potential errors.
Kameleoon uses tracking to count sessions and visitors when you call certain methods, such as
isFeatureActive(), getVariation() or getVariations().Use the default true value for the track parameter when you expose visitors to a variation and need to count them. Set the track parameter to false only if you call these methods before you expose visitors.For example, if you call getVariations() to retrieve all variations before you expose visitors, set the track parameter to false. This setting prevents Kameleoon from prematurely counting a session. You can then trigger tracking later when you explicitly expose the visitor.Kameleoon sends tracking data every second by default. You can configure this interval up to 5 seconds using the tracking interval configuration option. Kameleoon groups tracking events into a single session as long as the interval between events is less than 30 minutes. If more than 30 minutes elapse between tracking events, Kameleoon counts the events as separate sessions. A visit appears in your reports 30 minutes after the last recorded event in the session.Arguments
Return value
Errors thrown
getVariation()
- 📨 Sends Tracking Data to Kameleoon (depending on the
trackparameter)
Variation assigned to a given visitor for a specific feature flag.
This method takes a visitorCode and featureKey as mandatory arguments. The track argument is optional and defaults to true.
It returns the assigned Variation for the visitor. If the visitor isn’t associated with any feature flag rules, the method returns the default Variation for the given feature flag.
Ensure your code includes proper error handling to manage potential exceptions.
The default variation refers to the variation assigned to a visitor when they don’t match any predefined delivery rules for a feature flag. In other words, it’s the fallback variation applied to all users who aren’t targeted by specific rules. It’s represented as the variation in the “Then, for everyone else…” section in a management interface.
Parameters
Return value
Errors thrown
getVariations()
- 📨 Sends Tracking Data to Kameleoon (depending on the
trackparameter)
Variation objects assigned to a given visitor across all feature flags.
This method iterates over all available feature flags and returns the assigned Variation for each flag associated with the specified visitor. It takes onlyActive and track as optional arguments.
- If you set
onlyActivetotrue, the methodgetVariations()returns feature flag variations only if the visitor isn’t bucketed with theoffvariation. - The
trackparameter controls whether the method tracks the variation assignments. By default, it’strue. If it’sfalse, the method doesn’t track variation assignments.
Variation as values. If the SDK assigns no variation for a feature flag, the method returns the default Variation for that flag.
Implement proper error handling to manage potential exceptions.
The default variation refers to the variation assigned to a visitor when they don’t match any predefined delivery rules for a feature flag. In other words, it’s the fallback variation applied to all users who aren’t targeted by specific rules. It’s represented as the variation in the “Then, for everyone else…” section in a management interface.
Parameters
Return value
Errors thrown
setForcedVariation()
The method allows you to programmatically assign a specificVariation to a user, bypassing the standard evaluation process. The method is especially valuable for controlled experiments where the usual evaluation logic isn’t required or you need to skip it. It can also be helpful in scenarios like debugging or custom testing.
When you set a forced variation, it overrides Kameleoon’s real-time evaluation logic. The SDK skips processes like segmentation, targeting conditions, and algorithmic calculations. To preserve segmentation and targeting conditions during an experiment, set forceTargeting=false instead.
Kameleoon treats a forced variation the same as an evaluated variation. It’s tracked in analytics and stored in the user context like any standard evaluated variation, ensuring consistency in reporting.
The method may throw exceptions under certain conditions (for example, invalid parameters, user context, or internal issues). Proper exception handling is essential to ensure that your app remains stable and resilient.
Parameters
Errors thrown
In most cases, you only need to handle the basic error,
KameleoonError/KameleoonError.Feature, as the example demonstrates. However, if different types of errors require a response, handle each one separately based on specific requirements. Additionally, for enhanced reliability, you can handle general language errors by including Error.evaluateAudiences()
- 📨 Sends Tracking Data to Kameleoon
evaluateAudiences() after you set or update all relevant visitor data, and just before getting a feature variation or checking a feature flag. This approach ensures that Kameleoon evaluates the visitor against the most current data available, allowing for accurate audience assignment based on all criteria.
After calling this method, you can perform a detailed analysis of segment performance in Audiences Explorer.
Errors thrown
In most cases, you only need to handle the basic error,
KameleoonError/KameleoonError.Feature, as the example demonstrates. However, if different types of errors require a response, handle each one separately based on specific requirements. Additionally, for enhanced reliability, you can handle general language errors by including Error.getFeatureList()
Returns a list of feature flag keys available for the SDK.Return value
getDataFile()
Returns the current SDK configuration as aDataFile object.
Return value
Errors thrown
Goals
trackConversion()
- 📨 Sends Tracking Data to Kameleoon
goalId to track conversion on this particular goal. In addition, this method also accepts revenue, metadata and negative arguments.
The trackConversion() method doesn’t return any value. This method is non-blocking because the SDK makes the server call asynchronously.
Parameters
metadata values are accessible through raw data exports and the results page.If you provide the
metadata parameter, Kameleoon uses these specified values for the current conversion instead of what you previously collected using the addData() method. If you omit the parameter, Kameleoon uses the last tracked values for those CustomData prior to the conversion and within the same visit.Kameleoon will only consider the metadata values that are explicitly passed as parameters to the trackConversion() method.In the example below, Kameleoon will associate the conversion only with the custom data value explicitly provided as a parameter (here: index 5 with the value ‘Amex Credit Card’).Events
setEventHandler()
Use this method to register a handler for SDK events. The SDK calls the handler when the selected event occurs. Registering a new handler for the same event type replaces the previous handler. Passingnil as the handler removes the current handler for the selected event type.
- dataFileUpdate
- httpRequest
Parameters
Visitor data
visitorCode
Returns unique visitor code used in SDK.Return value
addData()
TheaddData() method adds targeting data to storage so other methods can use the data to decide whether or not to target the current visitor.
The addData() method doesn’t return any value and doesn’t interact with Kameleoon backend servers on its own. Instead, the SDK saves all the declared data for future transmission using the flush() method. This approach reduces the number of server calls made, as the data is typically grouped into a single server call that’s triggered by the flush().
The trackConversion() method also sends out any previously associated data, just like the flush(). The same holds true for getVariation() and getVariations() methods if an experimentation rule is triggered.
Parameters
flush()
- 📨 Sends Tracking Data to Kameleoon
flush() method collects the Kameleoon data linked to the visitor. It then sends a tracking request, along with all data added using the addData method that hasn’t yet been sent using one of these methods. flush() is non-blocking as the server call is made asynchronously.
flush provides control over when data associated with a given visitorCode is sent to the servers. For instance, if addData() is called a dozen times, sending data to the server each time addData() is invoked would be inefficient. Call flush() once.
Parameters
Errors thrown
getRemoteData()
- 🔄 Performs an asynchronous request
This method was previously called
retrieveDataFromRemoteSource, which was removed in SDK version 4.0.0 release.siteCode and the key argument (or the active visitorCode if the key is omitted). The visitorCode and siteCode are specified in KameleoonClientFactory.create(). Data can be stored quickly and conveniently on highly scalable remote servers using the Kameleoon Data API. The app can then retrieve the data using this method.
- Swift
- Swift (Async)
Parameters
getRemoteVisitorData()
- 🔄 Performs an asynchronous request
getRemoteVisitorData() is an asynchronous method for retrieving Kameleoon Visits Data for the visitor from the Kameleoon Data API. The method adds the data to storage for other methods to use when making targeting decisions.
Data obtained using this method plays an important role when you want to:
- use data collected from other devices.
- access a user’s history, such as custom data collected during previous visits.
By default,
getRemoteVisitorData() automatically retrieves the latest stored custom data with scope=Visitor and attaches them to the visitor without the need to call the method addData(). It’s particularly useful for synchronizing custom data between multiple devices.Checking only for failed results is recommended. However, if necessary, it can be verified that the data has been added to the visitor and is available for targeting purposes (or for debugging, though using logging is better for debugging). Additionally, data can be managed manually if the addData=false parameter is passed.- Swift
- Swift (Async)
Parameters
Using parameters with RemoteVisitorDataFilter
ThegetRemoteVisitorData() method offers flexibility by allowing you to define various parameters when retrieving data on visitors. Whether you’re targeting based on goals, experiments, or variations, the same approach applies across all data types.
For example, suppose you want to retrieve data on visitors who completed a goal “Order transaction.” You can specify parameters within the getRemoteVisitorData() method to refine your targeting. For instance, if you want to target only users who converted on the goal in their last five visits, you can set the previousVisitAmount parameter to 5 and conversions to true.
The flexibility shown in this example isn’t limited to goal data. You can use parameters within the getRemoteVisitorData() method to retrieve data on a variety of visitor behaviors.
Here is the list of available
Types.RemoteVisitorDataFilter options:getVisitorWarehouseAudience()
- 🔄 Performs an asynchronous request
warehouseKey parameter is typically your internal user ID. The customDataIndex parameter corresponds to the Kameleoon custom data that Kameleoon uses to target your visitors. You can refer to the warehouse targeting documentation for additional details.
- Swift
- Swift (Async)
Parameters
setLegalConsent()
You must use this method to specify whether the visitor has given legal consent to use their personal data. Setting thelegalConsent parameter to false limits the types of data that you can include in tracking requests. This method helps you adhere to legal and regulatory requirements while responsibly managing visitor data. You can find more information on personal data in the consent management policy.
Parameters
Data types
This section lists the data types supported by Kameleoon. Several standard data types are provided, as well as theCustomData type for defining custom data types.
Conversion
TheConversion data set stored here can be used to filter experiment and personalization reports by any goal associated with it.
CustomData
CustomData allows any type of data to be easily associated with each visitor. CustomData can then be used as a targeting condition in segments or as a filter/breakdown in experiment reports.
To learn more about custom data, refer to this article.
- Each visitor is allowed only one
CustomDatafor each uniqueindex. Adding anotherCustomDatawith the sameindexwill replace the existingCustomData. - The custom data
indexcan be found in the Custom Data dashboard under the “INDEX” column. - To prevent the SDK from sending data with the selected index to Kameleoon servers for privacy reasons, enable the Use this data only locally for targeting purposes option when creating custom data.
- Adding a
CustomDatainstance created with a name when the SDK instance configuration isn’t up to date or the name isn’t registered, will result in the data being ignored.
Device
Since iOS SDK
4.14.0, the Device is automatically detected based on the value of UIDevice.current.userInterfaceIdiom. However, you can still manually override it if needed.Geolocation
Geolocation contains the visitor’s geolocation details.
Returned types
DataFile
TheDataFile contains the SDK configuration details.
It can be extended with additional information if required by clients. If you need more details, contact your Customer Success Manager.
FeatureFlag
TheFeatureFlag represents a set of properties that define a feature flag itself (for example, its Variations, Rules, environment status, and other related details).
It can be extended with additional information if required by clients. If you need more details, contact your Customer Success Manager.
Rule
TheRule represents a set of properties that define a rule itself (for example, its Variations).
It can be extended with additional information if required by clients. If you need more details, contact your Customer Success Manager.
Variation
Variation contains information about the assigned variation to the visitor (or the default variation, if no specific assignment exists).
- The
Variationobject provides details about the assigned variation and its associated experiment, while theVariableobject contains specific details about each variable within a variation. - Ensure that your code handles the case where
idorexperimentIdmay be-1, indicating a default variation. - The
variablesmap might be empty if no variables are associated with the variation.
Variable
Variable contains information about a variable associated with the assigned variation.
Deprecated methods
getFeatureVariationKey()
- 📨 Sends Tracking Data to Kameleoon
Use
getVariation() instead.featureKey as a required argument to retrieve the variation key for the specified user.
If the visitor has never been associated with this feature flag, the SDK returns a randomly assigned variation key (according to the feature flag rules). If the visitor is already registered with this feature flag, this method returns the previous variation key. If the visitor doesn’t match any of the rules, the default variation you defined in the Kameleoon app will be returned.
Ensure you set up proper error handling as shown in the example code to catch potential errors.
getActiveFeatureList()
Use
getVariations() instead.Return value
getActiveFeatures()
Use
getVariations() instead.getActiveFeatures method retrieves information about the active feature flags that are available for the specified visitor code.
Return value
getFeatureVariable()
- 📨 Sends Tracking Data to Kameleoon
- Use
getVariation()instead. - This method was previously called
obtainFeatureVariable(), which was removed in SDK version4.0.0.
featureKey, and variableKey as required arguments to get the variable of the variation key for a given user.
If a visitor has never been associated with this feature flag, the SDK returns a variable value for the variation key that it randomly assigns according to the feature flag rules. If the user is already registered with this feature flag, the SDK returns the variable value for the previously associated variation. If the user doesn’t match any of the rules, the default variable is returned.
Parameters
Return value
Errors thrown
getFeatureVariationVariables()
- Use
getVariation()instead. - This method was previously called
getFeatureAllVariables, which was removed in SDK version4.0.0.
featureKey as an argument. It returns data with the [String: Any] type, as defined on the web interface. It will throw an exception (KameleoonError.Feature.notFound) if the requested feature hasn’t been found in the SDK’s internal configuration.
Parameters
Return value
Errors thrown
updateConfigurationHandler()
TheupdateConfigurationHandler() method allows you to handle the event when configuration has updated data. It takes one input parameter, handler. The handler that will be called when the configuration is updated using a real-time configuration event.