Known issues

  • 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.position string resource with your own, custom queue message. See Localizing the UI for more information.

  • There is an issue when the Chat account doesn't have any department in it, which disturbs the flow of the prechat. This results in the chat not being placed in the queue unless you send an additional message, after which everything works as normal. The workaround is simply adding a department to the chat account.

  • There are cases where the mobile UI looks frozen when an agent joins the session on Agent Workspace. From the agent side, everything will look normal. The end-user can still send messages but the UI won't refresh until the end of the session. The issue is around the agent avatar URL. Renaming the avatar URL with only Latin characters or removing the URL should fix the issue.

  • 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 weak reference 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 .viewDidDisappear and setting it to nil.

  • 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.

Department not set when using triggers to send greetings

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.

Example of a proactive message trigger in the Chat admin interface

### Resolved Issues

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

As of 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.

[Resolved (v2.10.0)] Provider API calls before opening the Chat screen

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.