Releases: launchdarkly/ios-client-sdk
[8.2.0] - 2023-08-02
Changed:
- Deprecated LDUser and related functionality. Use LDContext instead. To learn more, read https://docs.launchdarkly.com/home/contexts.
[8.1.0] - 2023-06-05
Changed:
- Enforce TLS v1.2 as a required minimum.
Fixed:
- Allow setting kind through
trySet
.
[8.0.1] - 2023-02-28
Fixed:
- Remove the extra
privateAttributes
meta field from the event payload. This extra field prevented LaunchDarkly services from accepting SDK events when private attributes were specified.
[8.0.0] - 2022-12-07
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."
This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.
If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.
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.
Added:
- The type
LDContext
defines the new context model. - For all SDK methods that took an
LDUser
parameter, there is now an overload that takes anLDContext
.
Changed:
- The
secondary
attribute which existed inLDUser
is no longer a supported feature. If you set an attribute with that name inLDContext
, it will simply be a custom attribute like any other. - Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.
- The SDK no longer adds
device
andos
values to the user attributes. Applications that wish to use device/OS information in feature flag rules must explicitly add such information.
Removed:
- Removed the
secondary
meta-attribute inLDUser
. - The
alias
method no longer exists because alias events are not needed in the new context model. - The
autoAliasingOptOut
andinlineUsersInEvents
options no longer exist because they are not relevant in the new context model.
[7.1.0] - 2022-11-08
Added:
- Added Objective C bindings for ApplicationInfo.
[7.0.0] - 2022-10-12
Changed:
- Dropped support for older versions in accordance with the new Xcode 14 release.
[6.2.0] - 2022-09-01
Added:
- CI builds now include a cross-platform test suite implemented in https://github.com/launchdarkly/sdk-test-harness. This covers many test cases that are also implemented in unit tests, but may be extended in the future to ensure consistent behavior across SDKs in other areas.
- Introduced ApplicationInfo, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
Changed:
- Updated LDSwiftEventSource to 2.0.0. We no longer bind to a static product; rather, we let the build determine static vs dynamic linking.
Fixed:
- Previously a deleted flag could be made available in the SDK if the deletion events were processed out of order. This is no longer the case.
[6.1.0] - 2022-05-17
Added
- Added the
LDUser.isAnonymousNullable
property that allows treating theisAnonymous
property as nullable.
Fixed
- Correctly track whether the
LDUser.isAnonymous
property was set explicitly (or by not specifying a key). The variation result for flag rules targeting theanonymous
property can differ depending on whether the property is set explicitly.
[6.0.0] - 2022-05-04
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.
Added
- Added the
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 typesObjcLDValue
andObjcLDValueType
for Objective-C interoperability. - Added the
UserAttribute
class which provides a less error-prone way to refer to user attribute names in configuration. - Added the type specific variation functions,
boolVariation
,intVariation
,doubleVariation
,stringVariation
, andjsonVariation
, toLDClient
. - Added the type specific detailed variation functions,
boolVariationDetail
,intVariationDetail
,doubleVariationDetail
,stringVariationDetail
, andjsonVariationDetail
, toLDClient
. - Added
jsonVariation
andjsonVariationDetail
toObjcLDClient
. These functions allow evaluating feature flags where the provideddefaultValue
and the resulting variation can be any valid JSON data type. - Added
ObjcLDJSONEvaluationDetail
for retrieving the detailed evaluation information of arbitrary type flag variations. - Added
ObjcLDChangedFlagHandler
type alias for new non-type specific Objective-C flag observers.
Changed (API)
LDClient.track(key: data: metricValue:)
no longerthrows
.- The type of the
data
parameter ofLDClient.track(key: data: metricValue:)
has changed fromAny?
toLDValue?
. ObjcLDClient.track(key: data:)
andObjcLDClient.track(key: data: metricValue:)
no longerthrows
. In Objective-C this change means that thetrack
functions no longer accept aerror:
parameter.- The type of the
data
parameter ofObjcLDClient.track(key: data:)
andObjcLDClient.track(key: data: metricValue)
has changed fromAny?
toObjLDValue?
. In Objective-C this would be a change fromid _Nullable
toLDValue * _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 fromNSDictionary<NSString*, id> * _Nullable
toNSDictionary<NSString*, LDValue*> * _Nullable
.- The type of the
LDUser.custom
dictionary, and the correspondingLDUser.init
parameter has been changed from[String: Any]?
to[String: LDValue]
. - The type of the
ObjcLDUser.custom
property has been changed from[String: Any]?
to[String: ObjcLDValue]
. In Objective-C this would be a change fromNSDictionary<NSString*, id> * _Nullable
toNSDictionary<NSString*, LDValue*> * _Nonnull
. - The type of the
LDUser.privateAttributes
property, and the correspondingLDUser.init
parameter, have been changed from[String]?
to[UserAttribute]
. - The type of the
ObjcLDUser.privateAttributes
property has been changed from[String]?
to[String]
. In Objective-C this would be a change fromNSArray<NSString*> * _Nullable
toNSArray<NSString*> * _Nonnull
. - The types of the properties
LDChangedFlag.oldValue
andLDChangedFlag.newValue
have been changed fromAny?
toLDValue
. - The type of the
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 fromNSArray<NSString*> * _Nullable
toNSArray<NSString*> * _Nonnull
.- The type of the
LDEvaluationDetail.reason
property has been changed from[String: Any]
to[String: LDValue]
. - The type of the
reason
property ofObjcLDBoolEvaluationDetail
,ObjcLDIntegerEvaluationDetail
,ObjcLDDoubleEvaluationDetail
, andObjcLDStringEvaluationDetail
has been changed from[String: Any]?
to[String: ObjcLDValue]?
. In Objective-C this would be a change fromNSDictionary<NSString*, id> * _Nullable
toNSDictionary<NSString*, LDValue*> * _Nullable
.
Changed (behavioral)
- The
Equatable
instance forLDUser
has been changed to compare all user properties, rather than just thekey
property. - Using
"custom"
as a private attribute name inLDConfig.privateUserAttributes
orLDUser.privateAttributes
will no longer set allLDUser
custom attributes private. - The automatically set
device
andoperatingSystem
custom attributes can now be set private. - SDK versions from 4.0.0 and less than 6.0.0 supported migration of cached flag data from any SDK version of at least 2.3.3. The 6.0.0 release only supports migration of cached flag data from SDK versions of at least 4.0.0.
Removed
- Removed
LDClient.variation(forKey: defaultValue:)
andLDClient.variationDetail(forKey: defaultValue:)
functions. Please use the new type-specific variation functions instead (e.g.LDClient.boolVariation(forKey: defaultValue:)
). - Removed the
LDFlagValueConvertible
protocol which was previously used to constrain the parameters and return types of the variation functions. LDErrorHandler
andLDClient.observeError(owner: handler:)
have been removed. Please useConnectionInformation
instead.- Removed the
LDUser.init(userDictionary: )
andObjcLDUser.init(userDictionary: )
initializers, please use the explicit initializers instead. - Removed
LDUser.CodingKeys
. To refer to user attributes, please useUserAttribute
instead. - Removed
LDUser.privatizableAttributes
andObjcLDUser.privatizableAttributes
. - Removed
ObjcLDUser.attributeCustom
. - The
LDUser.device
andLDUser.operatingSystem
properties, and the correspondingLDUser.init
parameters have been removed. These fields will be included in theLDUser.custom
dictionary. - The
ObjcLDUser.device
andObjcLDUser.operatingSystem
properties have been removed. These fields will be included in theObjcLDUser.custom
dictionary. - The
ObjcLDClient
functions,arrayVariation
,arrayVariationDetail
,dictionaryVariation
, anddictionaryVariationDetail
, have been removed. Please useObjcLDClient.jsonVariation
andObjcLDClient.jsonVariationDetail
instead. - The per-type instances of
ObjcLDChangedFlag
have been removed. Please use the base classObjcLDChangedFlag
, which now providesoldValue
andnewValue
ObjcLDValue
properties. The removed classes areObjcLDBoolChangedFlag
,ObjcLDIntegerChangedFlag
,ObjcLDDoubleChangedFlag
,ObjcLDStringChangedFlag
,ObjcLDArrayChangedFlag
, andObjcLDDictionaryChangedFlag
. - The classes
ObjcLDArrayEvaluationDetail
andObjcLDDictionaryEvaluationDetail
have been removed. Please useObjcLDJSONEvaluationDetail
instead. - The type aliases,
ObjcLDBoolChangedFlagHandler
,ObjcLDIntegerChangedFlagHandler
,ObjcLDDoubleChangedFlagHandler
,ObjcLDStringChangedFlagHandler
,ObjcLDArrayChangedFlagHandler
, andObjcLDDictionaryChangedFlagHandler
, have been removed. Please useObjcLDChangedFlagHandler
instead. - The
ObjcLDClient
functions,observeBool
,observeInteger
,observeDouble
,observeString
,observeArray
, andobserveDictionary
, have been removed. Please use the non-type specificObjcLDClient.observe(key: owner: handler:)
instead.
[5.4.5] - 2022-03-11
Fixed
- Fixed race condition in
LDSwiftEventSource
that could cause a crash if the stream is explicitly stopped (such as whenidentify
is called) while the stream is waiting to reconnect.