The Classic Chat SDK is not designed to have multiple instances running simultaneously. You can only use one instance of the Classic Chat SDK at a time in your app.
Changing the Chat account at runtime is not supported. While it is possible to initialize with one account and again with another during runtime, we do not support this configuration.
There is an issue when the Chat account doesn't have any department in it, which disturbs the flow of the pre-chat. 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.
If your account is using Agent Workspace, you will not receive a notification for the end of the Chat session. This is due to the termination of the session being different. We recommend your agents send a message before closing the chat to avoid uninformed termination.
The library can be compiled when Mac Catalyst is enabled even though Mac Catalyst is not supported.
There is an issue whereby text cells might not resize themselves accurately after a device rotation. This can result in messages missing some text.
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
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. The same can occur when using the SDK Provider to send a message progammatically when the chat session has barely been created.
While it is possible to create proactive greeting Chat triggers for the Zendesk Chat mobile SDKs (both iOS and Android) or to use sendMessage while using the Chat UI, due to race conditions inherent to Chat we do not recommend nor support the usage of proactive message with the Zendesk Chat mobile SDKs.
For example, these race conditions can prevent the setting of a department. Once a chat is started, the department field becomes read-only. If the greeting is sent before a department is set, you cannot set the department.
If you must use a trigger, one way to reduce these risks is to add a 'Still on site' condition to the trigger with a value of '1' where '1' is the number of seconds to wait. You can also add a condition on the trigger that requires the chat to have a department before the greetings are sent.
When moving your account to Agent Workspace, be aware that this will slightly change the way attachments behave in Chat SDK. The files received won't be opened directly, but will rather be opened via a browser in order to be downloaded.
This doesn't affect images that will still be rendered directly in the Chat UI.
When testing the SDK, ensure that you are testing on a physical device as some behaviors differ on an emulator.
Chat SDK doesn't take operating hours into account. It only considers if a department is online (at least one agent online within it) and if the account is online (at least one agent online) when preparing a Chat session. This means that users will be able to pick a department on the pre-chat form after operating hours if those conditions are met.