The Zendesk iOS SDK
Native support screens inside your iOS app, with the customer already identified and the device context attached. A day of work, and a long term dependency.
What you get
The iOS SDK puts Zendesk surfaces inside your own app instead of pushing people to a browser. Depending on which SDK line you adopt and what your account supports, that means some combination of:
Zendesk has reorganised its mobile SDK line-up more than once, and older package names still circulate in blog posts and Stack Overflow answers. Confirm current package names, minimum iOS version and support status in the current SDK reference before you commit to a dependency. The concepts below are stable. The exact symbols aren't.
The genuine argument for doing this rather than opening a browser is context. Your app already knows the account, the plan, the build number, the device and the screen the person was looking at when they gave up. Attach that on conversation creation and your first agent reply stops being a request for information the app was already holding. That alone removes a round trip from a large share of tickets. And a round trip is usually a day.
Installing the Zendesk iOS SDK
Swift Package Manager is the normal route now. In Xcode, add the package by URL, or declare it in your manifest. The shape looks like this, with the actual repository URL and version taken from the current SDK reference:
// Package.swift
dependencies: [
.package(url: "https://github.com/zendesk/<sdk-repo>", from: "1.0.0")
],
targets: [
.target(name: "MyApp", dependencies: [
.product(name: "ZendeskSDKMessaging", package: "<sdk-repo>")
])
]CocoaPods is still supported on the older lines. If your project is already on Pods, that's one line in the Podfile:
pod 'ZendeskSDKMessaging'Then the usual pod install, and open the workspace rather than the project file. Nothing exotic. Expect the SDK to pull in a handful of transitive dependencies and to bump your minimum deployment target, which is the first thing to check if your app still supports older iOS versions.
Initialising, in Swift
Initialisation happens once, early, usually in your app delegate or at scene setup. The messaging SDK is keyed by a channel key you create in Admin Center. The older support SDK wanted an app ID, client ID and subdomain URL instead, which is the fastest way to tell which generation a code sample belongs to.
import ZendeskSDKMessaging
import ZendeskSDKfunc application(_ application: UIApplication,
didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
Zendesk.initialize(withChannelKey: Secrets.zendeskChannelKey,
messagingFactory: DefaultMessagingFactory()) { result in
if case let .failure(error) = result {
Log.error("Zendesk init failed: \(error)")
}
}
return true
}Presenting the conversation is then a single call from whatever button your design team put it behind:
if let vc = try? Zendesk.instance?.messaging?.messagingViewController() {
navigationController.pushViewController(vc, animated: true)
}Treat those symbol names as illustrative. Check the current SDK reference for the exact initialiser signature and view controller accessor in the version you install, because they have changed between major releases.
Identity is the part that matters
Anonymous support in an app you're already signed into is a wasted opportunity. Authenticate the SDK and every conversation arrives attached to the right customer, with no mistyped email address and no anonymous requester to reconcile later.
The pattern is always the same. Your server signs a JWT with a secret only it holds, your app fetches that token, and the SDK asks for it through a callback when it needs one.
Zendesk.instance?.loginUser(with: jwtFromYourServer) { result in
switch result {
case .success(let user): Log.info("Zendesk user \(user.id)")
case .failure(let error): Log.error("Zendesk login failed: \(error)")
}
}Two rules, both non-negotiable. Never put the signing secret in the app binary, because anything compiled into an iOS app can be extracted and then anyone can impersonate any customer you have. And call the logout equivalent when your own session ends, or the next person to use that phone inherits a stranger's support history.
Push notifications and the ongoing cost
Push is where the integration earns its keep and where it takes the longest. You register APNs credentials with Zendesk, forward the device token to the SDK once the user is identified, and hand incoming payloads to the SDK from your notification delegate so it can decide whether a given notification belongs to it.
Apple changes requirements around notifications and privacy periodically, so this isn't a one-off. It's maintenance. Budget for it.
The wider honest point: an SDK is a dependency inside a release cycle. A fix ships at the speed of app review plus user update adoption, which is weeks, not minutes. Binary size grows. Major SDK versions bring breaking changes. If your app is a light front end for a website and mobile support volume is modest, a webview or a plain link to your help centre costs a fraction as much and is genuinely the right call. See the mobile SDK overview for that comparison in full.
Frequently asked questions
What does iOS SDK setup involve?
Zendesk SDK iOS setup is a dependency, an initialise call with your channel key, and an identity. The rest of a Zendesk iOS integration is push notifications, which is where the ongoing maintenance lives.
Which Zendesk iOS SDK should I use?
The messaging SDK for anything new, since that's where development is focused. The older support-style SDK still exists in some accounts. Check the current SDK reference for what your plan and channel configuration supports.
Does the Zendesk iOS SDK support SwiftUI?
The SDK surfaces are UIKit view controllers, which you wrap with UIViewControllerRepresentable in a SwiftUI app. That works fine, and it's what most teams do.
How do I identify signed-in users?
Sign a JWT on your server and pass it to the SDK login call. Never embed the signing secret in the app, because it can be extracted from the binary.
Do I need push notifications for it to be useful?
Not strictly, but without push the customer has to reopen your app to find out they got a reply. Push is the difference between a real support channel and a form.
Does it work with React Native or Flutter?
Through wrappers rather than first-class libraries in every case. Check what exists, who maintains it and how far behind the native SDK it lags before committing.
In-app tickets duplicate too
A customer who messages in the app and then emails you creates two tickets about one problem. Ticket Merger spots the pair.
Start free trial14-day free trial. No credit card required.