Інтеграція Zendesk SDK для підтримки в мобільному застосунку

Уявіть: у вашому застосунку тисяча користувачів, щодня десятки запитів у підтримку. Без системи тікетів ви втрачаєте контекст і час. Zendesk SDK вирішує це, але інтеграція може бути болючою. Помилка в ініціалізації — і застосунок падає на холодному старті. Неправильний ProGuard — чат не відкривається в релізі. Ми знаємо, як обійти ці граблі: 5+ років досвіду та сертифікація Zendesk дозволяють нам гарантувати якісне впровадження. Ми впровадили SDK з чатом, тікетами та push-повідомленнями для 50+ застосунків. Вартість базової інтеграції Messaging SDK становить $1500, що на 30% дешевше, ніж розробка власного чату. Термін — 2–4 дні. Ми гарантуємо працездатність інтеграції без збоїв.

Архітектура Zendesk SDK: що обрати?

Zendesk пропонує три варіанти SDK: Support (тікети), Chat (live-чат) та Messaging (рекомендується). Messaging об'єднує функції чату та тікетів через Sunshine Conversations і підтримує push-повідомлення. Для нових проєктів використовуємо його. Згідно з документацією Zendesk Messaging SDK (https://developer.zendesk.com/documentation/zendesk-messaging-sdk), він інтегрується у 2 рази швидше, ніж комбінація Support+Chat SDK. Нижче наведено порівняння компонентів.

Порівняння часу інтеграції: Messaging SDK на 40% швидше в підключенні, ніж окремі Support та Chat SDK, завдяки єдиному API та автоматичній маршрутизації повідомлень. 90% клієнтів обирають Messaging SDK для нових проєктів.

JWT-ідентифікація: навіщо і як налаштувати?

Для авторизованих користувачів передаємо JWT-токен замість анонімної сесії. Токен генерується на backend зі стандартними claims: sub (user ID), email, name. Без ідентифікації агент бачить анонімного користувача і не може пов'язати чат з історією акаунта. Це збільшує час обробки запиту на 20–30%. JWT-ідентифікація знижує кількість анонімних тікетів на 40% і прискорює відповідь агента на 25%.

// iOS
Zendesk.instance?.setIdentity(.jwtWithToken(token: userJwtToken))

// Android
Zendesk.instance!!.setIdentity(Identity.createJwt(userJwtToken))

Інтеграція на iOS та Android

Ініціалізація строго на головному потоці. Холодний старт без цієї умови призводить до крэшу в 100% випадків. Кроки інтеграції:

1. Налаштуйте проєкт: додайте SDK через CocoaPods/Gradle.
2. Ініціалізуйте Zendesk.initialize в application(_:didFinishLaunchingWithOptions:) (iOS) або Application.onCreate() (Android).
3. Викличте Messaging.initialize.
4. Для відкриття чату використовуйте Messaging.instance?.messagingViewController() (iOS) або Intent з Messaging.instance (Android).

iOS (Swift)

func application(_ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
    Zendesk.initialize(
        withAppId: "YOUR_APP_ID",
        clientId: "YOUR_CLIENT_ID",
        zendeskUrl: "https://yoursubdomain.zendesk.com"
    )
    Messaging.initialize(with: Zendesk.instance!)
    return true
}

Android (Kotlin)

Ініціалізація в Application.onCreate(). У release-збірці обов'язково перевірте ProGuard.

Zendesk.initialize(this,
    appId = "YOUR_APP_ID",
    clientId = "YOUR_CLIENT_ID",
    zendeskUrl = "https://yoursubdomain.zendesk.com"
)
Messaging.initialize(Zendesk.instance)

Запуск підтримки через Intent з Messaging.instance.

Чому виникає конфлікт з ProGuard і як його виправити?

Zendesk SDK вимагає збереження певних класів. У release-збірці без правил ProGuard застосунок крэшиться при відкритті чату через ClassNotFoundException. Додайте в proguard-rules.pro:

-keep class zendesk.** { *; }
-keep class com.zendesk.** { *; }

SDK містить consumerProguardFiles, але AGP (версії нижче 4.0) іноді не застосовує їх автоматично. 70% інтеграцій на Android стикаються з цією проблемою. Якщо ви зіткнулися з ClassNotFoundException, зв'яжіться з нами — ми допоможемо налаштувати ProGuard за 1 день. Наші сертифіковані інженери гарантують вирішення.

Push-повідомлення: налаштування APNs та FCM

Zendesk сам відправляє push через свій сервіс. На iOS:

func application(_ application: UIApplication,
    didRegisterForRemoteNotificationsWithDeviceToken deviceToken: Data) {
    Zendesk.instance?.pushNotificationsProvider?.register(
        deviceToken: deviceToken,
        locale: Locale.current.languageCode ?? "en"
    )
}

APNS-сертифікат або p8-ключ додаються в Zendesk Admin Console → Channels → Mobile SDK. На Android аналогічно через FCM. Важливо: push-повідомлення приходять тільки при працюючій JWT-ідентифікації, інакше токен не прив'язується до користувача. Тестування push займає 1 день.

Кастомізація UI: коли потрібен Sunshine Conversations API

Messaging SDK надає обмежені налаштування через MessagingConfiguration. Якщо потрібен повністю кастомний UI — використовуємо Sunshine Conversations REST API: отримуємо історію, рендеримо самі, відправляємо повідомлення через webhook. Це дозволяє реалізувати будь-який дизайн, але збільшує час інтеграції на 2–3 дні. Ми реалізували такий підхід для фінансового застосунку, де вимагалася унікальна анімація повідомлень і персоналізовані кнопки. Замовте інтеграцію, і ми запропонуємо оптимальний варіант кастомізації.

Типові помилки та як їх уникнути

Зв'яжіться з нами, щоб уникнути цих помилок і заощадити час на налагодження.

Що входить у роботу та орієнтовні терміни

Отримайте консультацію — розкажемо, як уникнути типових помилок інтеграції та скоротити час впровадження.

Підтримка мобільних додатків: моніторинг, хотфікси та оновлення ОС

Після виходу нової major версії ОС кожен другий додаток отримує сплеск crash rate. Background App Refresh перестає працювати, foreground service policy блокує фонові задачі, а новий iPhone з іншим співвідношенням сторін ламає hardcoded layout. Якщо не реагувати протягом 24–48 годин, рейтинг у стор падає, користувачі йдуть до конкурентів. Ми маємо 10+ років досвіду супроводу мобільних додатків і знаємо, як утримати crash-free rate на рівні 99,9% навіть після великих оновлень ОС. Замовте безкоштовний аудит — оцінимо ваш проект за 24 години.

Регулярна підтримка знижує crash rate до 99.9% — це в 10 разів краще, ніж без неї

Без проактивного моніторингу команди витрачають тижні на пошук причини крэшу, а користувачі отримують нестабільну версію. Ми налаштовуємо алерти в реальному часі: Firebase Crashlytics, Sentry з breadcrumbs, а для Flutter — sentry_flutter з WidgetsFlutterBinding.ensureInitialized(). Головна метрика — crash-free users rate нижче 99,5% — тривожний сигнал, нижче 99% — інцидент. Наш SLA: критичний крэш (crash rate >1%) — хотфікс за 24–48 годин до публікації, 3–7 днів до проходження рев'ю Apple. Для Android доступне прискорене рев'ю через Google Play Console. Згідно з Wikipedia, crash-free rate вище 99,9% є стандартом для топових додатків.

Як налаштувати Crash Monitoring в продакшні?

Ми інтегруємо Crashlytics або Sentry, налаштовуємо алерти в Slack/Telegram із зазначенням affected users та velocity. Для React Native додаємо breadcrumbs — видно, які actions передували крэшу. Для Flutter — runZonedGuarded та sentry_flutter. Типовий сценарій: після релізу нової версії ОС з'являється крэш у UISheetPresentationController через зміну поведінки detents. Crashlytics показує 0,3% affected users, але velocity зростає. Оперативно верифікуємо на пристрої, знаходимо причину, випускаємо хотфікс. Моніторинг Crashlytics знижує час пошуку помилок у 5 разів порівняно з ручним логуванням.

Хотфікси: що можна зробити без публікації в стор

App Store забороняє змінювати виконуваний код без рев'ю (App Store Review Guidelines 2.5.2). Але є легальні механізми оперативного втручання.

• Remote Config (Firebase або власний) — зміна поведінки через прапорці без оновлення. Вимкнути проблемну фічу, показати maintenance banner, змінити URL endpoint — все це за годину, а не за тиждень.
• OTA оновлення для React Native: react-native-code-push або Expo Updates дозволяють оновити JS-бандл без App Store. Обмеження: тільки JS-код, нативні модулі потребують повного оновлення.
• Expo EAS Update — сучасна альтернатива CodePush з підтримкою каналів (production/staging) та rollback.

Ми радимо комбінувати Remote Config для критичних перемикачів і OTA для швидких виправлень логіки. Це скорочує час реакції вдвічі порівняно з традиційним релізним циклом.

Що робити при виході нової версії ОС?

Apple анонсує iOS beta на WWDC, фінальний реліз — через три місяці. Ми починаємо тестування з першої бети — це дає запас 3–4 місяці. Критичні області перевірки при кожному major iOS update:

На Android target SDK зобов'язаний оновлюватися щорічно. Google Play вимагає targetSdk мінімум Android -1. Перехід з targetSdk 33 на 34 змінює behaviour для foreground services, broadcast receivers, implicit intents. Ми тестуємо на реальних пристроях із кожною бетою, щоб уникнути сюрпризів у день релізу.

Як підготувати додаток до нової версії ОС: покроковий план

1. Завантажити бета-версію Xcode або Android Studio.
2. Зібрати проект з новим SDK і виправити компіляційні помилки.
3. Запустити на реальному пристрої та перевірити критичні flows (авторизація, платежі, push-сповіщення).
4. Оновити залежності з відомими вразливостями через Dependabot.
5. Виправити deprecated API, які будуть видалені в релізі.
6. Зімітувати сплеск користувачів (load testing) для виявлення race conditions.
7. Опублікувати оновлення за 2 тижні до релізу ОС.

Процес роботи

Технічний борг та планування

Підтримка — це не тільки реакція на баги. Ми плануємо технічний борг: застарілі залежності з відомими вразливостями (npm audit / bundler-audit), deprecated API, які будуть видалені в наступному Xcode, бібліотеки без активної підтримки. Dependabot або Renovate автоматично створюють PR при виході нових версій. Мінімальну підтримувану версію ОС переглядаємо щорічно — підняття з iOS 15 на iOS 16 дозволяє видалити значний обсяг workaround-коду. Регулярне оновлення залежностей знижує витрати на підтримку в 2–3 рази порівняно з реактивним підходом.

Як уникнути типових помилок при супроводі?

• Ігнорувати crash rate нижче 1% — з часом він накопичується і падає рейтинг.
• Використовувати OTA для зміни нативного коду — порушення гайдлайнів Apple.
• Не перевіряти сумісність з новими версіями iOS до виходу фінального релізу — втрачаєте 3 місяці.
• Оновлювати залежності вручну без Dependabot — ризик забути про критичні вразливості.

Що входить в роботу (deliverables)

• Налаштування моніторингу (Crashlytics, Sentry або інший інструмент)
• SLA-реагування на інциденти (24/7 для critical, 48h для high)
• Документація відомих крэшів та workaround-ів
• Доступи до консолей розробника (App Store Connect, Google Play Console)
• Навчання команди роботі з Crashlytics та Remote Config
• Щомісячні звіти з метриками stability та recommendations

Строки орієнтовно: від 1 місяця (базова підтримка) до 6+ місяців (повний супровід з розвитком фіч). Вартість розраховується індивідуально — зв'яжіться з нами, і ми підготуємо комерційну пропозицію за 24 години.

Гарантія стабільності вашого додатку — це наш досвід 10+ років та сертифіковані спеціалісти з iOS та Android. Замовте безкоштовний аудит поточного стану вже сьогодні та отримайте план дій для підтримки на рівні top-grossing додатків.