Flagship Release Notes April 🐇
Last updated
Was this helpful?
Last updated
Was this helpful?
Check in QA that your hits have been configured correctly before launching a use case. For example, you may want to double check if the transactionID, the eventName, or the visitorID are correctly reflected in the reporting. Make sure that any event sent is received, and check that everything is properly configured:
Check all hits related to the use case
Check all payloads related to the hits
Check if your QA hits are received by confirming your visitorID
iOS SDK is now compatible with tvOS, watchOS & macOS!
This update allows you to manage features or experiment across smart devices that support tvOS, watchOS and macOS.
Cache management has been streamlined for the iOS SDK
To improve the development experience, we have streamlined and optimized the iOS SDK architecture and the way data is cached on SDKs. You can now customize the way the cache is managed. You (or your developers) can implement your own cache and tailor what it does or does not cache.
A quick reminder on what the cache offers natively:
Prevent user reassignment as the assignment is stored in the cache: a visitor will always be assigned to the same variation.
Prevent data loss as the cache stores the hit and returns it later in case of an issue.
Manage Offline moments. No connection, no worries, the SDK will take the last stored value.
Managing flags just got easier in the iOS SDK
The methods have been redesigned for easier implementation, more self-service and better accessibility of information ("all in one" method). We have revamped the getModification, getModificationInfo, activateModification and synchronizeModification methods to make them easier to understand.
From now on, the following methods will be swapped: getModification() -> getFlag(“newRelease”).value() getModificationInfo() -> getFlag(“newRelease”).metadata() activateModification() -> getFlag(“newRelease”).userExposed() synchronizeModification() -> fetchFlags()
