DocumentationAPI Reference

Getting support on our mobile SDKs

Troubleshooting mobile SDKs issues can be difficult. You need a lot of up-front information from your development team to troubleshoot a problem, and the nature of mobile development introduces many variables that makes diagnosing issues harder. To make the process smoother, here are some of the information that will help our Customer Support team assist you efficiently.

Note: We do not support any implementation of any of our mobile SDK within wrappers.

Include as much basic SDK information as possible

The information should include:

SDK version

This is necessary for our Customer Support team and developers to scope the issue.
If the issue started after upgrading to a more recent version, include that information. Our SDK documentation include release notes for each products as well as ongoing known issues for the latest version.
We recommend checking them to see if the issue you encounter is listed there.

Important: we will only investigate issue occuring on the latest version of the SDK or issue occuring when upgrading to the latest version of the SDK.

Operating system version

Often, issues are scoped to specific Android/iOS versions. Please include the OS versions you are testing with.

Logger results

Each section of documentation for our SDKs has a code snippet under “Debugging” or “Advanced topics” to add to your project to enable verbose logging. Enable it when reproducing the issue and provide any related logs when submitting a ticket. See the links below for the snippets:

iOS

Android

Recordings or screenshots

Any recording of the issue goes a long way, complements the logs very well, and simplifies the explanation of the issue.

Dependencies

If the issue mentions a library or one of the SDK dependencies, please consult the list of dependencies used in our SDKs. Using a higher version than the one documented can lead to unexpected results.

Initialization code

It is almost always helpful to include your initialization code to see how and when you’re starting up the SDK. If you have multiple SDK settings, this will help us know which one you are using.

Any code related to the issue. For example, if there’s a problem when loading articles, include the function that invokes the SDK article methods.

Timeline

When did the issue start? Has it always been an issue? Include a date when the behavior changed. Also include if the issue coincided with any code changes, such as an upgrade to a new version of a Zendesk SDK, other dependencies, or a change to your code.

Reproduction steps and pattern in occurence

If you are able to reproduce the issue, preferably in our demo apps (see below), please list them in the ticket. In the same manner, if the issue doesn't occur in every case but you can identify a pattern in those case, please add this information to the conversation.

Reproduce the issue in our demo app

There are up-to-date demo app repos for the Support, Chat, and Answer Bot SDKs. If you’re experiencing an issue such as a crash, UI display issues, authentication problems, or missing data or functionality (such as articles not appearing or triggers not firing), see if you can reproduce it in the corresponding demo app first. This will reduce variables unique to your app, and eliminate possible dependency conflicts.

iOS demo mobile apps

https://github.com/zendesk/ios_sdk_demo_apps (Support, Answer Bot and Chat)

Android demo mobile apps

https://github.com/zendesk/android_sdk_demo_apps (has modules for Support, Answer Bot and Chat)

If you can reproduce the issue in a demo app, outline the steps you took to do so, mention any code that you added or modified to reproduce the problem and send us a zip of the root folder of the demo app.

If you can’t reproduce the issue in a demo app, try creating a small example app that demonstrates the issue. See the next guideline for details.

Create an example app that demonstrates the issue

If you’re unable to reproduce the issue in a sample app, provide an example app that has the minimum possible code to reproduce the problem. For example, if there’s a conflict with another dependency, strip the app of everything except the SDK, the other dependency, and whatever code or UI is required to demonstrate the problem. You can use test data or test Zendesk user in your app to replicate the use case and remove any business logic so that only the relevant part related to the Zendesk issue remains.

Important: Due to the nature of custom development efforts, the Zendesk Customer Support and engineering teams do not troubleshoot and debug production applications. There will be many variables involved to effectively diagnose the issue. We need sample applications that demonstrate the problem in an isolated manner.

Advanced crash reports symbolication

dSYM files

When Xcode compiles your source code into machine code, it generates a list of symbols in your app (ie: Class names, global variables, method and function names). These symbols correspond to the file and line numbers where they are defined, such associations create a debug symbol.

When building your app in release mode, debug symbols are placed in a Debug Symbol file (dSYM).

dSYM files are useful for symbolicating crash reports and decoding a stack backtrace into a more readable format.

How to use dSYM files related to Zendesk SDKs

Zendesk SDK libraries are released as frameworks, all related dSYM files can be found in the .xcframework folder directory, in a .dSYMS folder.

For example, the Chat SDK dSYM folder can be found here.

If you encounter an issue with one of our SDKs, you can use its related dSYM files and upload them to the crash platform you use for crash reporting (ie: Crashlytics).