iOS SDK
$
npx @buildinternet/releases get launchdarkly-ios-sdkMon
Wed
Fri
SepOctNovDecJanFebMarAprMayJunJulAugSep
LessMore
Releases7Avg2/moVersionsv11.3.0 to v11.6.2
Last Checked
50m ago
npx @buildinternet/releases get launchdarkly-ios-sdkAll notable changes to the LaunchDarkly iOS SDK will be documented in this file. This project adheres to Semantic Versioning.
LDConfig.sendEvents option to disable all events (#414) (9a51844)This release introduces the ability to enable compression of event payloads. When enabled, the SDK will compress events before sending them to the LaunchDarkly servers. This can reduce the bandwidth required to send events, which can be useful in high-traffic environments to reduce egress traffic costs.
Important
Relay Proxy users MUST upgrade to version 8.9 or higher prior to enabling this option to prevent loss of event data.
However, enabling this feature is NOT required when using the Relay Proxy as it will manage compression automatically.
LDConfig.logger (#365) (eae8d78)start without a timeout parameter (#364) (65d88a4)identify() with a context that is identical to the SDK's current context is now more efficient, and no longer results in re-establishing a connection.identify() was called.LDValue.init(integerLiteral: Double) as this method signature is misleading. A new LDValue.init(integerLiteral: Int) signature has been added for clarity.identify() with a context that is identical to the SDK's current context is now more efficient, and no longer results in re-establishing a connection.identify() was called.LDValue.init(integerLiteral: Double) as this method signature is misleading. A new LDValue.init(integerLiteral: Int) signature has been added for clarity.trySet.privateAttributes meta field from the event payload. This extra field prevented LaunchDarkly services from accepting SDK events when private attributes were specified.The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."
For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide for Swift or Objective-C.
LDContext defines the new context model.LDUser parameter, there is now an overload that takes an LDContext.secondary attribute which existed in LDUser is no longer a supported feature. If you set an attribute with that name in LDContext, it will simply be a custom attribute like any other.device and os values to the user attributes. Applications that wish to use device/OS information in feature flag rules must explicitly add such information.secondary meta-attribute in LDUser.alias method no longer exists because alias events are not needed in the new context model.autoAliasingOptOut and inlineUsersInEvents options no longer exist because they are not relevant in the new context model.LDUser.isAnonymousNullable property that allows treating the isAnonymous property as nullable.LDUser.isAnonymous property was set explicitly (or by not specifying a key). The variation result for flag rules targeting the anonymous property can differ depending on whether the property is set explicitly.This major version has accompanying migration guides for Swift and Objective-C. Please see the guide for more information on updating to this version of the SDK, as the following is just a summary of the changes.
Note that Objective-C bridging types are prefixed by Objc, but that prefix is not exposed to code written in Objective-C. For example, changes listed to ObjcLDClient are changes to the class referred to as LDClient from within Objective-C.
LDValue class to represent any data type that is allowed in JSON. This new type is used to provide more type safety when representing complex or non-statically determined data types. The SDK also provides the bridge types ObjcLDValue and ObjcLDValueType for Objective-C interoperability.UserAttribute class which provides a less error-prone way to refer to user attribute names in configuration.boolVariation, intVariation, doubleVariation, stringVariation, and jsonVariation, to LDClient.boolVariationDetail, intVariationDetail, doubleVariationDetail, stringVariationDetail, and jsonVariationDetail, to LDClient.jsonVariation and jsonVariationDetail to ObjcLDClient. These functions allow evaluating feature flags where the provided defaultValue and the resulting variation can be any valid JSON data type.ObjcLDJSONEvaluationDetail for retrieving the detailed evaluation information of arbitrary type flag variations.ObjcLDChangedFlagHandler type alias for new non-type specific Objective-C flag observers.LDClient.track(key: data: metricValue:) no longer throws.data parameter of LDClient.track(key: data: metricValue:) has changed from Any? to LDValue?.ObjcLDClient.track(key: data:) and ObjcLDClient.track(key: data: metricValue:) no longer throws. In Objective-C this change means that the track functions no longer accept a error: parameter.data parameter of ObjcLDClient.track(key: data:) and ObjcLDClient.track(key: data: metricValue) has changed from Any? to ObjLDValue?. In Objective-C this would be a change from id _Nullable to LDValue * _Nullable.LDClient.allFlags now has the type [LDFlagKey: LDValue]? rather than [LDFlagKey: Any]?.ObjcLDClient.allFlags now has the type [String: ObjcLDValue]? rather than [String: Any]?. In Objective-C this would be a change from NSDictionary<NSString*, id> * _Nullable to NSDictionary<NSString*, LDValue*> * _Nullable.LDUser.custom dictionary, and the corresponding LDUser.init parameter has been changed from [String: Any]? to [String: LDValue].ObjcLDUser.custom property has been changed from [String: Any]? to [String: ObjcLDValue]. In Objective-C this would be a change from NSDictionary<NSString*, id> * _Nullable to NSDictionary<NSString*, LDValue*> * _Nonnull.LDUser.privateAttributes property, and the corresponding LDUser.init parameter, have been changed from [String]? to [UserAttribute].ObjcLDUser.privateAttributes property has been changed from [String]? to [String]. In Objective-C this would be a change from NSArray<NSString*> * _Nullable to NSArray<NSString*> * _Nonnull.LDChangedFlag.oldValue and LDChangedFlag.newValue have been changed from Any? to LDValue.LDConfig.privateUserAttributes property has been changed from [String]? to [UserAttribute].ObjcLDConfig.privateUserAttributes now has the non-optional type [String] rather than [String]?. In Objective-C this would be a change from NSArray<NSString*> * _Nullable to NSArray<NSString*> * _Nonnull.LDEvaluationDetail.reason property has been changed from [String: Any] to [String: LDValue].reason property of ObjcLDBoolEvaluationDetail, ObjcLDIntegerEvaluationDetail, ObjcLDDoubleEvaluationDetail, and ObjcLDStringEvaluationDetail has been changed from [String: Any]? to [String: ObjcLDValue]?. In Objective-C this would be a change from NSDictionary<NSString*, id> * _Nullable to NSDictionary<NSString*, LDValue*> * _Nullable.Equatable instance for LDUser has been changed to compare all user properties, rather than just the key property."custom" as a private attribute name in LDConfig.privateUserAttributes or LDUser.privateAttributes will no longer set all LDUser custom attributes private.device and operatingSystem custom attributes can now be set private.LDClient.variation(forKey: defaultValue:) and LDClient.variationDetail(forKey: defaultValue:) functions. Please use the new type-specific variation functions instead (e.g. LDClient.boolVariation(forKey: defaultValue:)).LDFlagValueConvertible protocol which was previously used to constrain the parameters and return types of the variation functions.LDErrorHandler and LDClient.observeError(owner: handler:) have been removed. Please use ConnectionInformation instead.LDUser.init(userDictionary: ) and ObjcLDUser.init(userDictionary: ) initializers, please use the explicit initializers instead.LDUser.CodingKeys. To refer to user attributes, please use UserAttribute instead.LDUser.privatizableAttributes and ObjcLDUser.privatizableAttributes.ObjcLDUser.attributeCustom.LDUser.device and LDUser.operatingSystem properties, and the corresponding LDUser.init parameters have been removed. These fields will be included in the LDUser.custom dictionary.ObjcLDUser.device and ObjcLDUser.operatingSystem properties have been removed. These fields will be included in the ObjcLDUser.custom dictionary.ObjcLDClient functions, arrayVariation, arrayVariationDetail, dictionaryVariation, and dictionaryVariationDetail, have been removed. Please use ObjcLDClient.jsonVariation and ObjcLDClient.jsonVariationDetail instead.ObjcLDChangedFlag have been removed. Please use the base class ObjcLDChangedFlag, which now provides oldValue and newValue ObjcLDValue properties. The removed classes are ObjcLDBoolChangedFlag, ObjcLDIntegerChangedFlag, ObjcLDDoubleChangedFlag, ObjcLDStringChangedFlag, ObjcLDArrayChangedFlag, and ObjcLDDictionaryChangedFlag.ObjcLDArrayEvaluationDetail and ObjcLDDictionaryEvaluationDetail have been removed. Please use ObjcLDJSONEvaluationDetail instead.ObjcLDBoolChangedFlagHandler, ObjcLDIntegerChangedFlagHandler, ObjcLDDoubleChangedFlagHandler, ObjcLDStringChangedFlagHandler, ObjcLDArrayChangedFlagHandler, and ObjcLDDictionaryChangedFlagHandler, have been removed. Please use ObjcLDChangedFlagHandler instead.ObjcLDClient functions, observeBool, observeInteger, observeDouble, observeString, observeArray, and observeDictionary, have been removed. Please use the non-type specific ObjcLDClient.observe(key: owner: handler:) instead.LDSwiftEventSource that could cause a crash if the stream is explicitly stopped (such as when identify is called) while the stream is waiting to reconnect.LDSwiftEventSource dependency to 1.3.0.delete flag stream events. This has been updated to allow additional fields for improved future compatibility.Throttler implementation to reduce concurrency concerns.Cartfile definining LDSwiftEventSource dependency, which when bundled could lead to warning messages that LDSwiftEventSource definitions are implemented in multiple frameworks.304 NOT_MODIFIED responses to SDK polling mode requests would be considered error responses. This could cause the completion on a identify request to not complete, and gave erroneous connection information data and logging output.null value nested within a JSON array.TimeInterval configuration options are set to sufficiently large values. This was caused when converting these values to an Int value of milliseconds. (Thanks, @delannoyk!)Package.swift to use SwiftPM tools version 5.2. This prevents test dependencies from being included transitively. (Thanks, @escakot!)Quick test dependency to 3.1.2 to avoid build warnings and adopt security fixes. (#243)AnyObject over class in protocol inheritance to avoid compiler warnings. (#247)identify to sometimes delay retrieving the most recent flags and calling the completion.alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.autoAliasingOptOut configuration option. This can be used to control the new automatic aliasing behavior of the identify method; by setting autoAliasingOptOut to true, identify will not automatically generate alias events.isInitialized property to LDClient. Unless the client has been set offline, this property's value is false until the client receives an initial set of flag values from the LaunchDarkly service. If the client is offline, the value will be true after initialization.identify method will now automatically generate an alias event when switching from an anonymous to a known user. This event associates the two users for analytics purposes as they most likely represent a single person.DiagnosticReporter implementation, which has been reworked to address these issues. Thanks to @provanandparanjape for one such report (#238).dispatch_group_leave.cold.1 that would rarely occur as the SDK transitioned to an online state for a given configuration or user. This issue may have been exacerbated for a short period due to a temporary change in the behavior of the LaunchDarkly service streaming endpoint. Thanks to all the users who reported (#235).LDSwiftEventSource dependency to correct an issue where a streaming connection could sometimes reconnect after being set offline.FlagStore from LDUser to fix a bug where multiple environments could overwrite each other's flag values.LDConfig the ability to dynamically configure the HTTP headers on requests through the headerDelegate property, which has the type RequestHeaderTransform.LDUser now has an optional secondary attribute to match other LaunchDarkly SDKs. For more on the behavior of this attribute see the documentation on targeting users.LDUser.privateAttributes or LDConfig.privateUserAttributes properties.LDConfig.additionalHeaders. This feature is to enable certain proxy configurations, and is not needed for normal use.