- There is an active issue with the dependency manager Carthage. It affects integrators that use Xcode's 11.4 command line tools and are trying to integrate the SDK. A workaround is to use an older version of command line tools until the Carthage team releases a fix.
- There is an issue whereby text cells might not resize themselves accurately after a device rotation. This can result in messages missing some text.
- Disabling or changing the default queue message requires overriding the
ios.conversation.ui.queue.positionstring resource with your own, custom queue message. See Localizing the UI for more information.
- You might need to keep reference to the view controller returned by the
Messaging.instance.buildUI(engines:configs:)function. If so, make sure it is a
weakreference to avoid any issues with the lifecycle of that view controller.
- There have been some reports of a weak reference keeping the MessagingUI view alive after a chat has ended, causing configuration issues with a second chat. You may need to deallocate the view by listening to
.viewDidDisappearand setting it to
- The Messaging UIViewController doesn't show bot or agent avatars.
- You can ignore the warning about "Class ZDKObservationToken is implemented in both ...MessagingAPI.framework/MessagingAPI and .../ChatProvidersSDK.framework/ChatProvidersSDK. One of the two will be used. Which one is undefined." We will attempt to remove this warning in the future, but it is a false positive, and can be safely ignored.
Chat triggers that send a greeting to the visitor can interfere with the SDK setting a department. You can add a 'Still on site' condition to the trigger with a value of '1' to avoid this. This is the number of seconds to wait.
Below is a list of all the previous known issues that have been resolved with the version that they were fixed in.
[Resolved (v2.11.1)] Assigning new ChatAPIConfiguration to Chat instance prevents pre-chat form from initiating Chat instantly
2.11.0, the Chat instance ignores subsequent requests of the same department name.
Direct assignment of the
ChatAPIConfiguration on the
Chat.instance causes an (internal) department request.
The UI layer also attempts to set the department at the end of the pre-chat form flow, which initiates the chat once the completion is fired.
Since this request follows the one set in the
ChatProvider layer, it is ignored. As a result the completion is never fired.
Once the user sends a follow-up message, the chat will start.
If you are using the config to modify the Chat experience, it is recommended to modify the existing object, as opposed to setting it directly.
It's likely you'd like to call some of the APIs before the visitor starts the chat to give the agent more context about the user. This is done through the different provider classes. An issue was introduced in v2.8.0 that causes all API calls to be cleared before they are sent. To ensure they are sent correctly, wrap the API calls inside a ConnectionStatus observer, and fire them once you are definitely connected.