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.
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 agent send a message before closing the chat to avoid uninformed termination.
Chat SDK doesn't take operating hours into account. It only considers if a department is online (at least 1 agent online within it) and if the account is online (at least 1 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.
Agent avatars that come from the Chat backend don't appear in the conversation thread, for API levels 16-19.
The Offline Form will only use known information when using JWT authentication. VisitorInfo will not be used to prefill the information of the Offline Form.
Going in and out of the Chat UI, can result in the UI being blank. If this occurs, the chat session is still working and the UI will come back after a new event is received by the UI such as a message received or sent.
Sometimes when you are typing in the Chat UI and you exit out of the it, the keyboard remains visible and you must manually close it. See Why is my keyboard not closing for a workaround that force closes the keyboard.
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.
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.