The Zendesk Support SDK for Mobile Apps
The Zendesk Support SDK puts native support inside your app with the customer already identified. Worth the integration work in some apps and clearly not in others.
What the Zendesk Support SDK is
Zendesk publishes iOS and Android libraries that put support surfaces inside your own app rather than sending people to a browser. The line-up has been reorganised over the years and older names still circulate, so confirm current package names and support status in the Zendesk developer docs before you add a dependency.
The two things that make it worth doing
Everything else is convenience. These two are structural.
Identity comes free. Your app already knows who the user is. Authenticate the SDK with a signed token and every ticket arrives attached to the right person, with no email address typed wrong and no anonymous requester to clean up later. On the web you fight for this. In an app you get it by default.
Context comes free too. App version, device model, OS version, locale, the screen they were on, their account tier. Attach it as custom fields on ticket creation and your first reply stops being a request for information the app already had. That alone can remove a full round trip from a large share of tickets.
The cost nobody budgets for
An SDK is a dependency in a mobile release cycle, and that's a different kind of commitment from a script tag.
It adds to binary size. It needs updating when the vendor ships breaking changes, when Apple or Google raise minimum OS versions, and when your own toolchain moves. A bug fix ships at the speed of app review and user update adoption, which is weeks, not minutes. And if your app is React Native or Flutter, you're depending on a wrapper as well as the SDK underneath it, with whatever lag that wrapper has.
None of that is a reason to avoid it. It is a reason to be honest that the true cost is the second year, not the first afternoon.
SDK, webview or a plain link
Three ways to put support in a mobile app, and what each one really costs.
| Native SDK | Webview | Link out to browser | |
|---|---|---|---|
| Integration effort | Days | Hours | Minutes |
| Feels native | |||
| User identified automatically | |||
| Device context attached | |||
| Push notifications for replies | |||
| Ships fixes without app release | |||
| Adds binary size and upkeep |
Push notifications and identity, the two setup jobs
Both need back end work, and both are the reason an SDK integration takes days rather than an afternoon.
Push. To notify a customer that their ticket was answered, Zendesk needs to reach your app, which means registering push credentials for each platform and passing a device token when the user is identified. Apple and Google both rotate their requirements periodically, so this is a thing you maintain rather than a thing you finish. When it works, it is the single most valuable part of the whole integration.
Identity. Generate a signed token on your server, never in the app binary. A secret compiled into a mobile app is extractable, and anyone who extracts it can impersonate any customer you have. Refresh the token when your own session refreshes, and clear the SDK session on sign out, or the next person to use that phone inherits a stranger support history.
Neither is difficult. Both get deferred to a later sprint and then quietly never happen, which leaves you with an SDK doing the job a webview would have done for a tenth of the effort.
Choosing between them
The rule of thumb is about how central support is to the app.
Use the SDK when people are signed in, when conversations are ongoing rather than one-off, and when device context genuinely changes the answer. A fintech app, a marketplace, a connected device companion app: all clear cases.
Use a webview or a link when your app is a light front end for a website, when support volume from mobile is small, or when your release cadence is slow enough that a bug in an embedded surface would sit there for a month. Sending someone to a well built help centre isn't a failure. A slow, poorly maintained native screen is worse than a fast web page.
Push notifications are the tiebreaker more often than teams expect. Being able to tell a customer their ticket was answered, in the app, without email, changes response rates enough to justify the work on its own.
Frequently asked questions
Is there a separate Zendesk Chat SDK for mobile?
There was. Older apps ship a Zendesk Chat SDK alongside the Support one, and newer builds use the unified messaging SDK instead. The Zendesk Android SDK and its iOS twin follow the same split.
What does the Zendesk Support SDK do?
It puts ticket creation and ticket history inside your iOS or Android app as native screens, so customers raise and follow requests without leaving it.
What is the difference between the Support SDK and the Chat SDK?
Support covers tickets and help centre content. Chat covers live conversation. Packaging has been reorganised over time, so check current Zendesk developer docs for what your account should install.
Can I identify signed-in app users automatically?
Yes, with a token signed on your server. That is the single biggest advantage over a webview, since tickets arrive attached to the right customer every time.
Is a webview good enough instead of the SDK?
Often, yes. If support volume from mobile is modest and users are not signed in, a webview or a browser link costs far less and ships fixes without an app release.
Do the SDKs support React Native and Flutter?
Through community and vendor wrappers rather than first-class libraries in every case. Check what exists and how actively it's maintained before committing.
The in-app ticket and the email that followed
Customers file in the app, get impatient and email as well. Ticket Merger matches the pair even when the app ticket has no email address on it.
Start free trial14-day free trial. No credit card required.